Method and apparatus for providing mobile and other intermittent connectivity in a computing environment

ABSTRACT

A seamless solution transparently addresses the characteristics of nomadic systems, and enables existing network applications to run reliably in mobile environments. The solution extends the enterprise network, letting network managers provide mobile users with easy access to the same applications as stationary users without sacrificing reliability or centralized management. The solution combines advantages of existing wire-line network standards with emerging mobile standards to create a solution that works with existing network applications. A Mobility Management Server coupled to the mobile network maintains the state of each of any number of Mobile End Systems and handles the complex session management required to maintain persistent connections to the network and to other peer processes. If a Mobile End System becomes unreachable, suspends, or changes network address (e.g., due to roaming from one network interconnect to another), the Mobility Management Server maintains the connection to the associated peer task—allowing the Mobile End System to maintain a continuous connection even though it may temporarily lose contact with its network medium. In one example, Mobility Management Server communicates with Mobile End Systems using Remote Procedure Call and Internet Mobility Protocols.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a division of application Ser. No. 09/330,310, filedJun. 11, 1999 now U.S. Pat. No. 6,546,425, entitled “Method AndApparatus For Providing Mobile And Other Intermittent Connectivity In AComputing Environment” which claims the benefit of provisionalapplication No. 60/103,598 filed Oct. 9, 1998 entitled “Method andApparatus For Providing Wireless Connectivity In A ComputingEnvironment” the entire content of each of which is hereby incorporatedby reference in this application.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

FIELD OF THE INVENTION

The present invention relates to connectivity between networkedcomputing devices. More particularly, the present invention relates tomethods and systems that transparently address the characteristics ofnomadic systems, and enable existing network applications to runreliably in the associated mobile environments. Still more particularly,the invention relates to techniques and systems for providing acontinuous data stream connection between intermittently-connecteddevices such as handheld data units and personal computing devices.

BACKGROUND AND SUMMARY OF THE INVENTION

Increasingly, companies are seeing rapid access to key information asthe way to maintaining a competitive advantage. To provide immediateaccess to this information, mobile and other intermittently-connectedcomputing devices are quietly and swiftly becoming an essential part ofcorporate networks—especially with the proliferation of inexpensivelaptops and hand-held computing devices. However, integrating thesenomadic devices into existing network infrastructures has created achallenge for the information manager.

Many problems in mobile networking parallel the difficulties in earlylocal area networks (LANs) before the adoption of Ethernet. There are avariety of mobile protocols and interfaces, and because standards arejust developing, there is little interoperability between systems. Inaddition, performance over these network technologies has been typicallyslow and bandwidth limited. Implementation costs to date have been highdue the specialized nature of deployed systems.

Along with these issues, mobile technologies present a category ofproblems unto their own. Interconnects back into the main network maytravel over and through a public network infrastructure, thus allowingsensitive information to possibly be tapped into. Furthermore, if any ofthe intermediary interconnects are via a wireless interface, theinformation is actually broadcast, and anyone with a similar interfacecan eavesdrop without much difficulty.

But, perhaps even more significantly, mobile networking has generally inthe past been limited to mostly message-oriented or statelessapplications—and thus has not been readily adaptable for existing or newcorporate applications that use client/server, host-terminal, web-basedor shared file systems models. This is because such commonly usedapplications need stateful sessions that employ a continuous stream ofdata—not just a stateless packet exchange—to work effectively andreliably.

To this end, many or most popular off-the-shelf networking applicationsrequire TCP/IP sessions, or private virtual circuits. These sessionscannot continue to function if they encounter network interruptions, norcan they tolerate roaming between networks (i.e., a change of networkaddresses) while established. Yet, mobile networking is, by its nature,dynamic and unreliable. Consider these common scenarios encountered inmobile networks:

Disconnected or Out of Range User

When a mobile device disconnects from a given network or loses contact(e.g., through an outage or “hole” in the coverage of a wirelessinterconnect), the session-oriented application running on the mobiledevice loses its stateful connection with its peer and ceases tooperate. When the device is reattached or moves back into contact, theuser must re-connect, log in again for security purposes, find the placein the application where work was left off, and possibly re-enter lostdata. This reconnection process is time consuming, costly, and can bevery frustrating.

Moving to a Different Network or Across a Router Boundary (NetworkAddress Change)

Mobile networks are generally segmented for manageability purposes. Butthe intent of mobile devices is to allow them to roam. Roaming from onenetwork interconnect to another can mean a change of network address. Ifthis happens while the system is operational, the routing informationmust be changed for communications to continue between the associatedpeers. Furthermore, acquiring a new network address may require all ofthe previously established stateful application sessions to beterminated—again presenting the reconnection problems noted above.

Security

As mentioned before, companies need to protect critical corporate data.Off-the-shelf enterprise applications are often written with theassumption that access to the physical network is controlled (i.e.,carried within cables installed inside a secure facility), and securityis maintained through an additional layer of authentication and possibleencryption. These assumptions have not been true in the nomadiccomputing world—where data is at risk for interception as it travelsover public airways or public wire-line infrastructures.

Summary

It would be highly desirable to provide an integrated solution thattransparently addresses the characteristics of nomadic systems, andenables existing network applications to run reliably in these mobileenvironments.

A presently preferred embodiment of the present invention solves thisproblem by providing a seamless solution that extends the enterprisenetwork, letting network managers provide mobile users with easy accessto the same applications as stationary users without sacrificingreliability or centralized management. The solution combines advantagesof present-day wire-line network standards with emerging mobilestandards to create a solution that works with existing networkapplications.

In accordance with one aspect of a presently preferred embodiment of thepresent invention, a Mobility Management Server (MMS) coupled to themobile interconnect maintains the state of each of any number of MobileEnd Systems (MES) and handles the complex session management required tomaintain persistent connections to the network and to peer applicationprocesses. If a Mobile End System becomes unreachable, suspends, orchanges network address (e.g., due to roaming from one networkinterconnect to another), the Mobility Management Server maintains theconnection to the associated peer—allowing the Mobile End System tomaintain a continuous virtual connection even though it may temporarilylose its actual physical connection.

A presently preferred exemplary embodiment of the present invention alsoprovides the following (among others) new and advantageous techniquesand arrangements:

-   -   a Mobility Management Server, providing user configurable        session priorities for mobile clients;    -   per-user mobile policy management for managing consumption of        network resources,    -   a roaming methodology making use of the industry standard        Dynamic Host Configuration Protocol (DHCP) in coordination with        a Mobility Management Server;    -   automatic system removal of unreliable datagrams based on user        configurable timeouts; and    -   automatic system removal of unreliable datagrams based on user        configurable retries.

In more detail, a presently preferred exemplary embodiment of thepresent invention in one of its aspects provides a Mobility ManagementServer that is coupled to the mobile interconnect (network). TheMobility Management Server maintains the state of each of any number ofMobile End Systems and handles the complex session management requiredto maintain persistent connections to the network and to other processes(e.g., running on other network-based peer systems). If a Mobile EndSystem becomes unreachable, suspends, or changes network address (e.g.,due to roaming from one network interconnect to another), the MobilityManagement Server maintains the connection to the associated peer, byacknowledging receipt of data and queuing requests. This proxying by theMobility Management Server allows the application on the Mobile EndSystem to maintain a continuous connection even though it maytemporarily lose its physical connection to a specific network medium.

In accordance with another aspect of a presently preferred exemplaryembodiment of the present invention, a Mobility Management Servermanages addresses for Mobile End Systems. Each Mobile End System isprovided with a proxy address on the primary network. This highlyavailable address is known as the “virtual address” of the Mobile EndSystem. The Mobility Management Server maps the virtual addresses tocurrent “point of presence” addresses of the nomadic systems. While thepoint of presence address of a Mobile End System may change when themobile system changes from one network interconnect to another, thevirtual address stays constant while any connections are active orlonger if the address is statically assigned.

In accordance with yet another aspect of a presently preferred exemplaryembodiment of the present invention, a Mobility Management Serverprovides centralized system management of Mobile End Systems through aconsole application and exhaustive metrics. A presently preferredexemplary embodiment of the present invention also provides userconfigurable session priorities for mobile clients running through aproxy server, and per-user mobile policy management for managingconsumption of network resources.

In accordance with yet another aspect of a presently preferred exemplaryembodiment of the present invention, a Remote Procedure Call protocoland an Internet Mobility Protocol are used to establish communicationsbetween the proxy server and each Mobile End System.

Remote procedure calls provide a method for allowing a process on alocal system to invoke a procedure on a remote system. The use of theRPC protocol allows Mobile End Systems to disconnect, go out of range orsuspend operation without losing active network sessions. Since sessionmaintenance does not depend on a customized application, off-the-shelfapplications will run without modification in the nomadic environment.

The Remote Procedure Call protocol generates transactions into messagesthat can be sent via the standard network transport protocol andinfrastructure. These RPC messages contain the entire networktransaction initiated by an application running on the Mobile EndSystem—enabling the Mobility Management Server and Mobile End System tokeep connection state information synchronized at all times—even duringinterruptions of the physical link connecting the two. In the preferredembodiment of a presently preferred exemplary embodiment of the presentinvention providing RPC's, the proxy server and the Mobile End Systemsshare sufficient knowledge of each transaction's state to maintaincoherent logical database about all shared connections at all times.

The Internet Mobility Protocol provided in accordance with a presentlypreferred exemplary embodiment of the present invention compensates fordifferences between wired local area network interconnects and otherless reliable networks such as a wireless LAN or WAN. Adjusted framesizes and protocol timing provide significant performance improvementsover non-mobile-aware transports—dramatically reducing network traffic.This is important when bandwidth is limited or when battery life is aconcern. The Internet Mobility Protocol provided in accordance with apresently preferred exemplary embodiment of the present invention alsoensures the security of organizational data as it passes between theMobile End System and the Mobility Management Server over public networkinterconnects or airways. The Internet Mobility Protocol provides abasic firewall function by allowing only authenticated devices access tothe organizational network. The Internet Mobility Protocol can alsocertify and encrypt all communications between the Mobility ManagementServer and the Mobile End System.

In accordance with yet another aspect of a presently preferred exemplaryembodiment of the present invention, mobile inter-connectivity is builton standard transport protocols (e.g., TCP/IP, UDP/IP and DHCP, etc) toextend the reach of standard network application interfaces. A presentlypreferred exemplary embodiment of the present invention efficientlyintegrates transport, security, address management, device managementand user management needs to make nomadic computing environmentseffectively transparent. The Internet Mobility Protocol provides anefficient mechanism for multiplexing multiple streams of data (reliableand unreliable) through a single virtual channel provided by suchstandard transport protocols over standard network infrastructure.

With the help of the RPC layer, the Internet Mobility Protocol coalescesdata from different sources targeted for the same or differentdestinations, together into a single stream and forwards it over amobile link. At the other end of the mobile link, the data isdemultiplexed back into multiple distinct streams, which are sent on totheir ultimate destination(s). The multiplexing/demultiplexing techniqueallows for maximum use of available bandwidth (by generating the maximumsized network frames possible), and allows multiple channels to beestablished (thus allowing prioritization and possibly providing aguaranteed quality of service if the underlying network provides theservice).

The Internet Mobility Protocol provided in accordance with a presentlypreferred exemplary embodiment of the present invention provides theadditional features and advantages, for example:

-   -   Transport protocol independence.    -   Allows the network point of presence (POP) or network        infrastructure to change without affecting the flow of data        (except where physical boundary, policy or limitations of        bandwidth may apply).    -   Minimal additional overhead.    -   Automatic fragment resizing to accommodate the transmission        medium. (When the protocol data unit for a given frame is        greater then the available maximum transmission unit of the        network medium, the Internet Mobility Protocol will fragment and        reassemble the frame to insure that it can traverse the network.        In the event of a retransmit, the frame will again be assessed.        If the network infrastructure or environment changes, the frame        will be refragmented or in the case that the maximum        transmission unit actually grew, sent as a single frame.)    -   Semantics of unreliable data are preserved, by allowing frames        to discard unreliable data during retransmit.    -   Provides a new semantic of Reliable Datagram service. (Delivery        of datagrams can now be guaranteed to the peer terminus of the        Internet Mobility Protocol connection. Notification of delivery        can be provided to a requesting entity.)    -   Considers the send and receive transmission path separately, and        automatically tailors its operating parameters to provided        optimum throughput. (Based on hysteresis, it adjusts such        parameters as frame size/fragmentation threshold, number of        frames outstanding (window), retransmit time, and delayed        acknowledgement time to reduce the amount of duplicate data sent        through the network.)    -   Network fault tolerant (since the expected usage is in a mobile        environment, temporary loss of network medium connectivity does        not result in a termination of the virtual channel or        application based connection).    -   Provides an in-band signaling method to its peer to adjust        operating parameters (each end of the connection can alert its        peer to any changes in network topology or environment).    -   Employs congestion avoidance algorithms and gracefully decays        throughput when necessary.    -   Employs selective acknowledgement and fast retransmit policies        to limit the number of gratuitous retransmissions, and provide        faster handoff recovery in nomadic environments. (This also        allows the protocol to maintain optimum throughput in a lossy        network environment.)    -   Employs sliding window technology to allow multiple frames to be        outstanding. (This parameter is adjustable in each direction and        provides for streaming frames up to a specified limit without        requiring an acknowledgement from its peer.)    -   Sequence numbers are not byte oriented, thus allowing for a        single sequence number to represent up to a maximum payload        size.    -   Security aware. (Allows for authentication layer and encryption        layer to be added in at the Internet Mobility Protocol layer.)    -   Compression to allow for better efficiency through bandwidth        limited links.    -   Balanced design, allowing either peer to migrate to a new point        of presence.    -   Either side may establish a connection to the peer.    -   Allows for inactivity timeouts to be invoked to readily discard        dormant connections and recover expended resources.    -   Allows for a maximum lifetime of a given connection (e.g., to        allow termination and/or refusal to accept connections after a        given period or time of day).

A presently preferred exemplary embodiment of the present invention alsoallows a system administrator to manage consumption of networkresources. For example, the system administrator can place controls onMobile End Systems, the Mobility Management Server, or both. Suchcontrols can be for the purpose, for example, of managing allocation ofnetwork bandwidth or other resources, or they may be related to securityissues. It may be most efficient to perform management tasks at theclient side for clients with lots of resources. However, thin clientsdon't have many resources to spare, so it may not be practical to burdenthem with additional code and processes for performing policymanagement. Accordingly, it may be most practical to perform or sharesuch policy management functions for thin clients at a centralized pointsuch as the Mobility Management Server. Since the Mobility ManagementServer proxies the distinct data streams of the Mobile End Systems, itprovides a central point from which to conduct policy management.Moreover, the Mobility Management Server provides the opportunity toperform policy management of Mobile End Systems on a per user and/or perdevice basis. Since the Mobility Management Server is proxying on a peruser basis, it has the ability to control and limit each user's accessto network resources on a per-user basis as well as on a per-devicebasis.

As one simple example, the Mobility Management Server can “lock out”certain users from accessing certain network resources. This isespecially important considering that interface network is via a mobileinterconnect, and may thus “extend” outside of the boundaries of alocked organizational facility (consider, for example, an ex-employeewho tries to access the network from outside his former employer'sbuilding). However, the policy management provided by the MobilityManagement Server can be much more sophisticated. For example, it ispossible for the Mobility Management Server to control particular WebURL's particular users can visit, filter data returned by networkservices requests, and/or compress data for network bandwidthconservation. This provides a way to enhance existing and newapplication-level services in a seamless and transparent manner.

A presently preferred exemplary embodiment of the present invention thusextends the enterprise network, letting network managers provide mobileusers with easy access to the same applications as stationary userswithout sacrificing reliability or centralized management. The solutioncombines advantages of existing wire-line network standards withemerging mobility standards to create a solution that works withexisting network applications.

BRIEF DESCRIPTION OF THE DRAWINGS

These, as well as other features and advantages of this invention, willbe more completely understood and appreciated by careful study of thefollowing more detailed description of presently preferred exampleembodiments of the invention taken in conjunction with the accompanyingdrawings, of which:

FIG. 1 is a diagram of an overall mobile computing network provided inaccordance with a presently preferred exemplary embodiment of thepresent invention;

FIG. 2 shows an example software architecture for a Mobile End Systemand a Mobility Management Server;

FIG. 2A shows example steps performed to transfer information between aMobile End System and a Mobility Management Server;

FIG. 3 shows an example mobile interceptor architecture;

FIG. 3A is a flowchart of example steps performed by the mobileinterceptor;

FIG. 3B is a flowchart of example steps performed by an RPC engine tohandle RPC work requests;

FIGS. 4-5C are flowcharts of example steps to process RPC work requests;

FIG. 6 is a diagram of an example received work request;

FIG. 7 is a diagram showing how a received work request can bedispatched onto different priority queues;

FIGS. 8 and 9 show processing of the contents of the different priorityqueues;

FIGS. 10A-15B show example steps performed to provide an InternetMobility Protocol;

FIG. 16 shows example listener data structures; and

FIGS. 17, 17A and 18 are flowcharts of example steps performed toprovide for mobile interconnect roaming.

DETAILED DESCRIPTION OF PRESENTLY PREFERRED EXAMPLE EMBODIMENTS

FIG. 1 is an example of mobile enhanced networked computer system 100provided in accordance with a presently preferred exemplary embodimentof the present invention. Networked computer system 100 includes aMobility Management Server 102 and one or more Mobile End Systems 104.Mobile End Systems 104 can communicate with Mobility Management Server102 via a local area network (LAN) 108. Mobility Management Server 102serves as network level proxy for Mobile End Systems 104 by maintainingthe state of each Mobile End System, and by handling the complex sessionmanagement required to maintain persistent connections to any peersystems 110 that host network applications—despite the interconnectbetween Mobile End Systems 104 and Mobility Management Server 102 beingintermittent and unreliable. In the preferred embodiment, MobilityManagement Server 102 communicates with Mobile End Systems 104 usingRemote Procedure Call and Internet Mobility Protocols in accordance witha presently preferred exemplary embodiment of the present invention.

In this particular example, Mobile End Systems 104 are sometimes but notalways actively connected to Mobility Management Server 102. Forexample:

-   -   Some Mobile End Systems 104 a-104 k may communicate with        Mobility Management Server 102 via a mobile interconnect        (wirelessly in this case), e.g., conventional electromagnetic        (e.g., radio frequency) transceivers 106 coupled to wireless (or        wire-line) local area or wide area network 108. Such mobile        interconnect may allow Mobile End Systems 104 a-104 k to “roam”        from one cover area 107 a to another coverage area 107 k.        Typically, there is a temporary loss of communications when a        Mobile End System 104 roams from one coverage area 107 to        another, moves out of range of the closest transceiver 106, or        has its signal temporarily obstructed (e.g., when temporarily        moved behind a building column or the like).    -   Other Mobile End Systems 1041, 104 m, . . . may communicate with        Mobility Managements Server 102 via non-permanent wire-based        interconnects 109 such as docking ports, network cable        connectors, or the like. There may be a temporary loss of        communications when Mobile End Systems 104 are temporarily        disconnected from LAN 108 by breaking connection 109, powering        off the Mobile End Systems, etc.    -   Still other Mobile End Systems (e.g., 104 n) may be nomadically        coupled to Mobility Management Server 102 via a further network        topography 111 such as a wide area network, a dial-up network, a        satellite network, or the Internet, to name a few examples. In        one example, network 111 may provide intermittent service. In        another example, Mobile End Systems 104 may move from one type        of connection to another (e.g., from being connected to Mobility        Management Server 102 via wire-based interconnect 109 to being        connected via network 111, or vice versa)—its connection being        temporarily broken during the time it is being moved from one        connection to another.

Mobile End Systems 104 may be standard mobile devices and off the shelfcomputers. For example, Mobile End System 104 may comprise a laptopcomputer equipped with a conventional radio transceiver and/or networkcards available from a number of manufacturers. Mobile End Systems 104may run standard network applications and a standard operating system,and communicate on the transport layer using a conventionally availablesuite of transport level protocols (e.g., TCP/IP suite.) In accordancewith the present invention, Mobile End Systems 104 also execute clientsoftware that enables them to communicate with Mobility ManagementServer 102 using Remote Procedure Call and Internet Mobility Protocolsthat are transported using the same such standard transport levelprotocols.

Mobility Management Server 102 may comprise software hosted by aconventional Windows NT or other server. In the preferred embodiment,Mobility Management Server 102 is a standards-compliant, client-serverbased intelligent server that transparently extends the enterprisenetwork 108 to a nomadic environment. Mobility Management Server 102serves as network level proxy for each of any number of Mobile EndSystems 104 by maintaining the state of each Mobile End System, and byhandling the complex session management required to maintain persistentconnections to any peer systems 110 that host networkapplications—despite the mobile interconnect between Mobile End Systems104 and transceivers 106 being intermittent and unreliable.

For example, server 102 allows any conventional (e.g., TCP/IP based)network application to operate without modification over mobileconnection. Server 102 maintains the sessions of Mobile End Systems 104that disconnect, go out of range or suspend operation, and resumes thesessions when the Mobile End System returns to service. When a MobileEnd System 104 becomes unreachable, shuts down or changes its point ofpresence address, the Mobility Management Server 102 maintains theconnection to the peer system 110 by acknowledging receipt of data andqueuing requests until the Mobile End System once again becomesavailable and reachable.

Server 102 also extends the management capabilities of wired networks tomobile connections. Each network software layer operates independentlyof others, so the solution can be customized to the environment where itis deployed.

As one example, Mobility Management Server 102 may be attached to aconventional organizational network 108 such as a local area network orwide area network. Network 108 may be connected to a variety offixed-end systems 110 (e.g., one or most host computers 110). MobilityManagement Server 102 enables Mobile End Systems 104 to communicate withFixed End System(s) 110 using continuous session type data streams eventhough Mobile End Systems 104 sometimes lose contact with theirassociated network interconnect or move from one network interconnect106, 109, 111 to another (e.g., in the case of wireless interconnect, byroaming from one wireless transceiver 106 coverage area 107 to another).

A Mobile End System 104 establishes an association with the MobilityManagement Server 102, either at startup or when the Mobile End Systemrequires network services. Once this association is established, theMobile End System 104 can start one or more network applicationsessions, either serially or concurrently. The Mobile End System104-to-Mobility Management Server 102 association allows the Mobile EndSystem to maintain application sessions when the Mobile End System,disconnects, goes out of range or suspends operation, and resumesessions when the Mobile End System returns to service. In the preferredembodiment, this process is entirely automatic and does not require anyintervention on the user's part.

In accordance with an aspect of a presently preferred exemplaryembodiment of the present invention, Mobile End Systems 104 communicatewith Mobility Management Server 102 using conventional transportprotocols such as, for example, UDP/IP. Use of conventional transportprotocols allows Mobile End Systems 104 to communicate with MobilityManagement Server 102 using the conventional routers 112 and otherinfrastructure already existing on organization's network 108. Inaccordance with a presently preferred exemplary embodiment of thepresent invention, a higher-level Remote Procedure Call protocolgenerates transactions into messages that are sent over the mobileenhanced network 108 via the standard transport protocol(s). In thispreferred embodiment, these mobile RPC messages contain the entirenetwork transaction initiated by an application running on the MobileEnd System 104, so it can be completed in its entirety by the MobilityManagement Server. This enables the Mobility Management Server 102 andMobile End System 104 to keep connection state information synchronizedat all times—even during interruptions of network medium connectivity.

Each of Mobile End Systems 104 executes a mobility management softwareclient that supplies the Mobile End System with the intelligence tointercept all network activity and relay it via the mobile RPC protocolto Mobility Management Server 102. In the preferred embodiment, themobility management client works transparently with operating systemfeatures present on Mobile End Systems 104 (e.g., Windows NT, Windows98, Windows 95, Windows CE, etc.) to keep client-site applicationsessions active when contact is lost with the network.

Mobility Management Server 102 maintains the state of each Mobile EndSystem 104 and handles the complex session management required tomaintain persistent connections to associated peer 108 such as hostcomputer 110 attached to the other end of the connection end point. If aMobile End System 104 becomes unreachable, suspends, or changes networkaddress (e.g., due to roaming from one network interconnect to another),the Mobility Management Server 102 maintains the connection to the hostsystem 110 or other connection end-point, by acknowledging receipt ofdata and queuing requests. This proxy function means that the peerapplication never detects that the physical connection to the Mobile EndSystem 104 has been lost—allowing the Mobile End System's application(s)to effectively maintain a continuous connection with its associatedsession end point (by simply and easily resuming operations once aphysical connection again is established) despite the mobile systemtemporarily losing connection or roaming from one network interconnect106A to another network interconnect 106K within coverage area 107K.

Mobility Management Server 102 also provides address management to solvethe problem of Mobile End Systems 104 receiving different networkaddresses when they roam to different parts of the segmented network.Each Mobile End System 104 is provided with a virtual address on theprimary network. Standard protocols or static assignment determine thesevirtual addresses. For each active Mobile End System 104, MobilityManagement Server 102 maps the virtual address to the Mobile EndSystem's current actual (“point of presence”) address. While the pointof presence address of a Mobile End System 104 may change when thedevice changes from one network segment to another, the virtual addressstays constant while any connections are active or longer if the addressis assigned statically.

Thus, the change of a point of presence address of a Mobile End System104 remains entirely transparent to an associated session end point onhost system 110 (or other peer) communicating with the Mobile End Systemvia the Mobility Management Server 102. The peer 110 sees only the(unchanging) virtual address proxied by the server 102.

In the preferred embodiment, Mobility Management Server 102 can alsoprovide centralized system management through console applications andexhaustive metrics. A system administrator can use these tools toconfigure and manage remote connections, and troubleshoot remoteconnection and system problems.

The proxy server function provided by Mobility Management Server 102allows for different priority levels for network applications, users andmachines. This is useful because each Mobility Management Server 102 iscomposed of finite processing resources. Allowing the system manager toconfigure the Mobility Management Server 102 in this way providesenhanced overall system and network performance. As one example, thesystem manager can configure Mobility Management Server 102 to allowreal time applications such as streaming audio or video to have greateraccess to the Mobility Management Server 102's resources than other lessdemanding applications such as email.

In more detail, Mobility Management Server 102 can be configured via anapplication or application interface; standard network managementprotocols such as SNMP; a Web-based configuration interface; or a localuser interface. It is possible to configure association priority and/orto configure application priority within an association. For example,the priority of each association relative to other associations runningthrough the Mobility Management Server 102 is configurable by either theuser name, or machine name (in the preferred embodiment, when thepriority is configured for both the user and the machine that a user islogged in on, the configuration for the user may have higherprecedence). In addition or alternatively, each association may haveseveral levels of application priority, which is configured based onnetwork application name. The system allows for any number of prioritylevels to exist. In one particular implementation, three priority levelsare provided: low, medium and high.

Server and Client Example Software Architecture

FIG. 2 shows an example software architecture for Mobile End System 104and Mobility Management Server 102. In accordance with one aspect of apresently preferred exemplary embodiment of the present invention,Mobile End System 104 and Mobility Management Server 102 run standardoperating system and application software—with only a few new componentsbeing added to enable reliable and efficient persistent sessionconnections over an intermittently connected mobile network 108. Asshown in FIG. 2, Mobile End System 104 runs conventional operatingsystem software including network interface drivers 200, TCP/UDPtransport support 202, a transport driver interface (TDI) 204, and asocket API 206 used to interface with one or more conventional networkapplications 208. Conventional network file and print services 210 mayalso be provided to communicate with conventional TDI 204′n. Server 102may include similar conventional network interface drivers 200, TCP/UDPtransport support 202′, a transport driver interface (TDI) 204, and asocket API 206′ used o interface with one or more conventional networkapplications 208′. Mobile End System 104 and Mobility Management Server102 may each further include conventional security software such as anetwork/Security provider 236 (Mobile End System) and a user/securitydatabase 238 (server).

In accordance with one exemplary aspect of the present invention, a new,mobile interceptor component 212 is inserted between the TCP/UDPtransport module 202 and the transport driver interface (TDI) 204 of theMobile End System 104 software architecture. Mobile interceptor 212intercepts certain calls at the TDI 204 interface and routes them viaRPC and Internet Mobility Protocols and the standard TCP/UDP transportprotocols 202 to Mobility Management Server 102 over network 108. Mobileinterceptor 212 thus can intercept all network activity and relay it toserver 102. Interceptor 212 works transparently with operating systemfeatures to allow client-side application sessions to remain active whenthe Mobile End System 104 loses contact with network 108.

While mobile interceptor 212 could operate at a different level than thetransport driver interface 204 (e.g., at the socket API level 206),there are advantages in having mobile interceptor 212 operate at the TDIlevel. Many conventional operating systems (e.g., Microsoft Windows 95,Windows 98, Windows NT and Windows CE) provide TDI interface 204—thusproviding compatibility without any need to change operating systemcomponents. Furthermore, because the transport driver interface 204 is akernel level interface, there is no need to switch to user mode—thusrealizing performance improvements. Furthermore, mobile interceptor 212working at the level of TDI interface 204 is able to intercept from avariety of different network applications 208 (e.g., multiplesimultaneously running applications) as well as encompassing networkfile and print services 210 (which would have to be handled differentlyif the interceptor operated at the socket API level 206 for example).

FIG. 2A shows an example high level flowchart of how mobile interceptor212 works. A call to the TDI interface 204 of Mobile End System 104(block 250) is intercepted by mobile interceptor 212 (block 252). Mobileinterceptor 212 packages the intercepted RPC call in a fragment inaccordance with an Internet Mobility Protocol, and sends the fragment asa datagram via a conventional transport protocol such as UDP or TCP overthe LAN, WAN or other transport 108 to Mobility Management Server 102(block 252). The Mobility Management Server 102 receives and unpackagesthe RPC datagram (block 254), and provides the requested service (forexample, acting as a proxy to the Mobile End System application 208 bypassing data or a response to an application server process running onFixed End System 110).

Referring once again to FIG. 2, Mobility Management Server 102 includesan address translator 220 that intercepts messages to/from Mobile EndSystems 104 via a conventional network interface driver 222. Forexample, address translator 230 recognizes messages from an associatedsession peer (Fixed End System 110) destined for the Mobile End System104 virtual address. These incoming Mobile End System messages areprovided to proxy server 224, which then maps the virtual address andmessage to previously queued transactions and then forwards theresponses back to the current point of presence addresses being used bythe associated Mobile End System 104.

As also shown in FIG. 2, Mobility Management Server 102 includes, inaddition to address translation (intermediate driver) 220, and proxyserver 224, a configuration manager 228, a control/user interface 230and a monitor 232. Configuration management 228 is used to provideconfiguration information and parameters to allow proxy server 224 tomanage connections. Control, user interface 230 and monitor 232 allow auser to interact with proxy server 214.

Mobile Interceptor

FIG. 3 shows an example software architecture for mobile interceptor 212that support the RPC Protocol and the Internet Mobility Protocol inaccordance with a presently preferred exemplary embodiment of thepresent invention. In this example, mobile interceptor 212 has twofunctional components:

-   -   a Remote Procedure Call protocol engine 240; and    -   an Internet Mobility Protocol engine 244.

Mobile interceptor 212 in the preferred embodiment thus supports RemoteProcedure Call protocol and Internet Mobility Protocol to connectMobility Management Server 102 to each Mobile End System 104. Remoteprocedure calls provide a method for allowing a process on a localsystem to invoke a procedure on a remote system. Typically, the localsystem is not aware that the procedure call is being executed on aremote system. The use of RPC protocols allows Mobile End System 104 togo out of range or suspend operation without losing active networksessions. Since session maintenance does not depend on a customizedapplication, off-the-shelf applications will run without modification inthe mobile environment of network 108.

Network applications typically use application-level interfaces such asWindows sockets. A single call to an application-level API may generateseveral outgoing or incoming data packets at the transport, or mediaaccess layer. In prior mobile networks, if one of these packets is lost,the state of the entire connection may become ambiguous and the sessionmust be dropped. In the preferred exemplary embodiment of the presentinvention providing RPCs, the Mobility Management Server 102 and theMobile End Systems 104 share sufficient knowledge of the connectionstate to maintain a coherent logical link at all times—even duringphysical interruption.

The Internet Mobility Protocol provided in accordance with a presentlypreferred exemplary embodiment of the present invention compensates fordifferences between wire-line and other less reliable networks such aswireless. Adjusted frame sizes and protocol timing provide significantperformance improvements over non-mobile-aware transports—dramaticallyreducing network traffic. This is important when bandwidth is limited orwhen battery life is a concern.

The Internet Mobility Protocol provided in accordance with a presentlypreferred embodiment of the present invention also ensure the securityof organization's data as it passes between the Mobile End System 104and the Mobility Management Server 102 on the public wire-line networksor airway. The Internet Mobility Protocol provides a basic firewallfunction by allowing only authenticated devices access to theorganizational network. The Internet Mobility Protocol can also certifyand encrypt all communications between the mobility management system102 and the Mobile End System 104.

The Remote Procedure Call protocol engine 240 on Mobile End System 104of FIG. 3 marshals TDI call parameters, formats the data, and sends therequest to the Internet Mobility Protocol engine 244 for forwarding toMobility Management Server 102 where the TDI Remote Procedure Callengine 240′ executes the calls. Mobile End Systems 104 martial TDI callparameters according to the Remote Procedure Call protocol. When theMobility Management Server 102 TDI Remote Procedure Call protocol engine240′ receives these RPCs, it executes the calls on behalf of the MobileEnd System 104. The Mobility Management Server 102 TDI Remote ProcedureCall protocol engine 240′ shares the complete network state for eachconnected Mobile End System with the peer Mobile End System 104's RPCengine 240. In addition to performing remote procedure calls on behalfof the Mobile End Systems 104, the server RPC engine 240′ is alsoresponsible for system flow control, remote procedure call parsing,virtual address multiplexing (in coordination with services provided byaddress translator 220), remote procedure call transactionprioritization, scheduling, and coalescing.

The Internet Mobility Protocol engine 244 performs reliable datagramservices, sequencing, fragmentation, and re-assembly of messages. Itcan, when configured, also provide authentication, certification, dataencryption and compression for enhanced privacy, security andthroughput. Because the Internet Mobility Protocol engine 244 functionsin power-sensitive environments using several different transports, itis power management aware and is transport independent.

FIG. 3A shows an example process mobile interceptor 212 performs tocommunicate a TDI call to Mobility Management Server 102. Generally, themobile interceptor RPC protocol engine 240 forwards marshaled TDI callsto the Internet Mobility Protocol engine 244 to be transmitted to theMobility Management Server 102. RPC protocol engine 240 does this byposting the RPC call to a queue maintained by the Internet MobilityProtocol engine 244 (block 302). To facilitate bandwidth management, theInternet Mobility Protocol engine 244 delays sending received RPC callsfor some period of time (“the RPC coalesce time out period”) (block304). Typically, the RPC coalesce timeout is set between five andfifteen milliseconds as one example but is user configurable. This delayallows the RPC engine 240 to continue posting TDI calls to the InternetMobility Protocol engine 244 queue so that more than one RPC call can betransmitted to the Mobility Management Server 102 in the same datagram(fragment).

When the coalesce timer expires, or the RPC protocol engine 240determines that it will not be receiving more RPC calls (decision block306), the RPC engine provides the Internet Mobility Protocol engine 244with a request to flush the queue, coalesce the RPC calls into a singleframe, and forward the frame to its peer (block 308). This coalescingreduces the number of transmissions—enhancing protocol performance.

As mentioned above, Mobility Management Server 102 proxy server also hasan RPC protocol engine 212′ and an Internet Mobility Protocol engine244′. FIG. 3B shows an example process performed by Mobility ManagementServer 102 upon receipt of an Internet Mobility Protocol message framefrom Mobile End System 104. Once the frame is received by the MobilityManagement Server 102, the Internet Mobility Protocol engine 244′reconstructs the frame if fragmented (due to the maximum transmissionsize of the underlying transport) and then demultiplexes the contents ofthe message to determine which Mobile End System 104 it was receivedfrom. This demultiplexing allows the Internet Mobility Protocol 244′ toprovide the Remote Procedure Call engine 240′ with the correctassociation-specific context information.

The Internet Mobility Protocol engine 244′ then formulates the receivedmessage into a RPC receive indication system work request 354, andprovides the Mobility Management Server 102 RPC engine 240′ with theformulated work request and association-specific context information.When RPC protocol engine 240′ receives work request 352, it places itinto an association-specific work queue 356, and schedules theassociation to run by providing a scheduled request to a global queue358. The main work thread of RPC engine 240′ is then signaled that workis available. Once the main thread is awake, it polls the global queue358 to find the previously queued association scheduled event. It thende-queues the event and begins to process the association-specific workqueue 356.

On the association specific work queue 356 it finds the previouslyqueued RPC receive indication work request The main thread thende-queues the RPC receive indication work request 356 and parses therequest. Because of the coalescing described in connection with FIG. 3A,the Mobility Management Server 102 often receives several RPCtransactions bundled in each datagram. It then demultiplexes each RPCtransaction back into distinct remote procedure calls and executes therequested function on behalf of Mobile End System 104. For performancepurposes RPC engine 240′ may provide a look ahead mechanism during theparsing process of the RPC messages to see if it can execute some of therequested transactions concurrently (pipelining).

How RPC Protocol Engine 240′ Runs RPC Associations

FIG. 4 is a flowchart of an example process for running RPC associationsplaced on an association work queue 356. When an RPC association isscheduled to run, the main thread for the RPC protocol engine 240′(which may be implemented as a state machine) de-queues the work requestfrom global work queue 358 and determines the type of work request.

There are six basic types of RPC work requests in the preferredembodiment:

-   -   schedule request;    -   connect indication;    -   disconnect indication;    -   local terminate association;    -   “resources available” request; and    -   ping inactivity timeout.        RPC protocol engine 240′ handles these various types of requests        differently depending upon their type. RPC protocol engine 240′        tests the request type (indicated by information associated with        the request as stored on global queue 358) in order to determine        how to process the request.

If the type of work request is a “schedule request” (decision block360), the RPC engine 240′ determines which association is beingscheduled (block 362). RPC engine 240′ can determine this informationfrom what is stored on global queue 358. Once the association is known,RPC engine 240′ can identify the particular one of association workqueues 356(1) . . . 356(n) the corresponding request is stored on. RPCengine 362 retrieves the corresponding association control block (block362), and calls a Process Association Work task 364 to begin processingthe work in a specific association's work queue 356 as previously noted.

FIG. 5 shows example steps performed by the “process association work”task 364 of FIG. 4. Once the specific association has been determined,this “process association work” task 364 is called to process the workthat resides in the corresponding association work queue 356. If thede-queued work request (block 390) is an RPC receive request (decisionblock 392), it is sent to the RPC parser to be processed (block 394).Otherwise, if the de-queued work request is a pending receive request(decision block 396), the RPC engine 240′ requests TDI 204′ to startreceiving data on behalf of the application's connection (block 398). Ifthe de-queued work request is a pending connect request (decision block400), RPC engine 240′ requests TDI 204′ to issue an applicationspecified TCP (or other transport protocol) connect request (block 402).It then waits for a response from the TDI layer 204′. Once the requestis completed by TDI 204′, its status is determined and then reportedback to the original requesting entity. As a performance measure, RPCengine 240′ may decide to retry the connect request process some numberof times by placing the request back on the associations-specific workqueue (356) before actually reporting an error back to the requestingpeer. This again is done in an effort to reduce network bandwidth andprocessing consumption.

The above process continues to loop until a “scheduling weight complete”test (block 404) is satisfied. In this example, a scheduling weight isused to decide how many work requests will be de-queued and processedfor this particular association. This scheduling weight is aconfiguration parameter set by configuration manager 228, and isacquired when the association connect indication occurs (FIG. 4, block372). This value is configurable based on user or the physicalidentification of the machine.

Once the RPC engine is finished with the association work queue 356 (forthe time at least), it may proceed to process dispatch queues (block406) (to be discussed in more detail below). If, after processing workon the association's work queue 356, more work remains in theassociation work queue, the RPC engine 240′ will reschedule theassociation to run again at a later time by posting a new schedulerequest to the global work queue 358 (FIG. 4, decision block 366, block368; FIG. 5, decision block 408, block 410).

Referring once again to FIG. 4, if the RPC work requested is a “connectindication” (decision block 370), RPC engine 240′ is being requested toinstantiate a new association with a mobile peer (usually, but notalways, the Mobile End System 104). As one example, the connectindication may provide the RPC engine 240′ with the followinginformation about the peer machine which is initiating the connection:

-   -   physical identifier of the machine,    -   name of the user logged into the machine,    -   address of the peer machine, and    -   optional connection data from the peer RPC engine 240.

In response to the connect indication (decision block 370), the RPCengine 240 calls the configuration manager 228 with these parameters.Configuration manager 228 uses these parameters to determine the exactconfiguration for the new connection. The configuration (e.g.,association scheduling weight and the list of all applications thatrequire non-default scheduling priorities along with those priorities)is then returned to the RPC engine 240′ for storage and execution. RPCengine 240′ then starts the new association, and creates a newassociation control block (block 372). As shown in FIG. 5A the followingactions may be taken:

-   -   allocate and association control block (block 372A);    -   initialize system wide resources with defaults (block 372B);    -   get configuration overrides with current configuration settings        (block 372C);    -   initialize flags (block 372D);    -   initialize the association-specific work queue (block 372E);    -   initialize association object hash table (block 372F);    -   initialize the coalesce timer (block 372G); and    -   insert association control block into session table (block        372H).

A “disconnect indication” is issued by the Internet Mobility Protocolengine 244′ to the RPC engine 240′ when the Internet Mobility Protocolengine has determined that the association must be terminated. The RPCengine 240′ tests for this disconnect indication (block 374), and inresponse, stops the association and destroys the association controlblock (block 376). As shown in FIG. 5B, the following steps may beperformed:

-   -   mark the association as deleted to prevent any further        processing of work that may be outstanding (block 376A);    -   close all associated association objects including process,        connection and address objects (block 376B);    -   free all elements on work queue (block 376C);    -   stop coalesce timer if running (block 376D);    -   decrement association control block reference count (block        376E); and    -   if the reference count is zero (tested for by block 376F):    -   destroy association specific work queue,    -   destroy object hash table,    -   destroy coalesce timer,    -   remove association control block from association table, and    -   free control block (376G).

A “terminate session” request is issued when system 100 has determinedthat the association must be terminated. This request is issued by thesystem administrator, the operating system or an application. RPC engine240′ handles a terminate session request in the same way it handles adisconnect request (decision block 378, block 376).

In the preferred embodiment, the interface between the RPC engine 240′and the Internet Mobility Protocol engine 244′ specifies a flow controlmechanism based on credits. Each time one thread posts a work request toanother thread, the call thread returns the number of credits left inthe work queue. When a queue becomes full, the credit count goes tozero. By convention, the calling thread is to stop posting further workonce the credit count goes to zero. Therefore, it is necessary to have amechanism to tell the calling thread that “resources are available” oncethe queued work is processed and more room is available by some userconfigurable/pre-determined low-water mark in the queue. This is thepurpose of the “resources available” work indication (tested for bydecision block 380). As shown in FIG. 5C, the following steps may beperformed when the credit count goes to zero:

-   -   mark association as “low mark pending” by setting the        RPC_LMPQ_SEND_FLAG (block 379A). Once in this state:    -   all received datagrams are discarded (block 379B);    -   all received stream events are throttled by refusing to accept        the data (block 379C) (this causes the TCP or other transport        receive window to eventually close, and provides flow control        between the Fixed End System 110 and the Mobility Management        Server 102; before returning, the preferred embodiment jams a        “pending receive request” to the front of the association        specific work queue 356 so that outstanding stream receive event        processing will continue immediately once resources are made        available).    -   all received connect events are refused for passive connections        (block 379D).

When the “resources available” indication is received by the RPC engine240′ (FIG. 4, decision block 380), the RPC engine determine whether theassociation has work pending in its associated association work queue356; if it does, the RPC engine marks the queue as eligible to run byposting the association to the global work queue 358 (block 382). If apending receive request has been posted during the time the associationwas in the low mark pending state, it is processed at this time (in thepreferred embodiment, the RPC engine 240′ continues to accept anyreceived connect requests during this processing).

Referring once again to FIG. 4, if RPC engine 240′ determines that theMobility Management Server 102 channel used for “ping” has been inactivefor a specified period of time (decision block 384), the channel isclosed and the resources are freed back to the system to be used byother processes (block 386).

RPC Parsing and Priority Queuing

Referring back to FIG. 5, it was noted above that RPC engine parsed anRPC receive request upon receipt (see blocks 392, block 394). Parsing isnecessary in the preferred embodiment because a single received datagramcan contain multiple RPC calls, and because RPC calls can span multipleInternet Mobility Protocol datagram fragments. An example format for anRPC receive work request 500 is shown in FIG. 6. Each RPC receive workrequest has at least a main fragment 502(1), and may have any number ofadditional fragments 502(2) . . . 502(N). Main fragment 502(1) containsthe work request structure header 503 and a receive overlay 504. Thereceive overlay 504 is a structure overlay placed on top of the fragment502(1) by the Internet Mobility Protocol engine 244. Within this overlay504 is a structure member called pUserData that points to the first RPCcall 506(1) within the work request 500.

The FIG. 6 example illustrates a work request 500 that contains severalRPC calls 506(1), 506(2) . . . 506(8). As shown in the FIG. 6 example,an RPC work request 500 need not be contained in a contiguous block ofmemory or in a single fragment 502. In the example shown, a secondfragment 502(2) and a third fragment 502(3) that are chained together tothe main fragment 502(1) in a linked list.

Thus, RPC parser 394 in this example handles the following boundaryconditions:

-   -   each RPC receive request 500 may contain one or more RPC calls;    -   one or more RPC calls 506 may exist in a single fragment 502;    -   each RPC call 506 may exist completely contained in a fragment        502; and    -   each RPC call 506 may span more than one fragment 502.

FIG. 7 shows an example RPC parser process 394 to parse an RPC receivework request 500. In this example, the RPC parser 394 gets the firstfragment 502(1) in the work request, gets the first RPC call 506(1) inthe fragment, and parses that RPC call. Parser 394 proceeds through theRPC receive work request 500 and processes each RPC call 506 in turn. Ifthe number of fragment bytes remaining in the RPC receive work request500 fragment 502(1) is greater than the size of the RPC header 503,parser 394 determines whether the RPC call is fully contained within theRPC fragment 502 and thus may be processed (this may be determined bytesting whether the RPC call length is greater than the number offragment bytes remaining). If the RPC call type is a chain exception,then the RPC call will handle the updating of the RPC parser 394 state.In the proxy server 224, the only RPC calls using the chain exceptionare the “datagram send” and “stream send” calls. This chain exceptionprocedure is done to allow the RPC engine to avoid fragment copies bychaining memory descriptor lists together for the purpose of RPC sendcalls.

Once the parser 394 identifies an RPC call type, a pointer to thebeginning of the RPC information is passed to the RPC engine 240 forexecution. The RPC engine divides all TDI procedure calls into differentpriorities for execution. The highest priority calls are immediatelyexecuted by passing them to an RPC dispatcher 395 for immediateexecution. All lower priority calls are dispatched to dispatch queues510 for future processing. Each dispatch queue 510 represents a discretepriority.

In the preferred embodiment, mobile applications call the “open address”object and “open connection” object functions before executing other TDInetworking functions. Therefore, the system assigns application levelpriorities during the “open address” object and “open connection” objectcalls. In the example embodiment, once an address or connection objectis assigned a priority, all calls that are associated with that objectare executed within that assigned priority.

If, for example, the RPC call is a TDI Open Address Object request or aTDI Open Connection Object Request, it is sent to the RPC dispatcher 395for immediate execution. The Open Address and Open Connection object RPCcalls provide access to a process ID or process name that are used tomatch against the information provided by the configuration manager 228during the configuration requests that occurs within the associationconnect indication described earlier. This is used to acquireconfiguration for the address or connection object.

In the preferred embodiment, all RPC calls have at least and addressobject or connection object as a parameter. When the call is made, thepriority assigned to that specific object is used as the priority forthe RPC call. The configuration assigned to the address or connectionobject determines which priority all associated RPC calls will beexecuted in. For example, if the assigned priority is “high,” all RPCcalls will be executed immediately without being dispatched to adispatch queue 510. If the assigned priority is “1,” all RPC calls willbe placed into dispatch queue 510(1).

Referring once again to FIG. 5, once the “process association work” task364 process has completed executing its scheduled amount of associationwork (decision block 404), it checks to see if the dispatch queuesrequire servicing (block 406). FIG. 8 is a flowchart of example stepsperformed by the “process dispatch queues” block 406 of FIG. 5 toprocess the dispatch queues 510 shown in FIG. 7.

In this example, dispatch queues 510 are processed beginning with thehighest priority queue (510(1) in this example) (block 408). Each queue510 is assigned a weight factor. The weight factor is a configurationparameter that is returned by the configuration manager 228 when aMobile End System 104 to Mobility Management Server 102 association iscreated. As one example, low priority dispatch queues 510 can have aweight factor of 4, and medium priority queues can have a weight factorof 8. High priority RPC calls do not, in this example, use weightfactors because they are executed immediately as they are parsed.

RPC engine 240′ loops through the de-queuing of RPC calls from thecurrent queue until either the queue is empty or the queue weight numberof RPC calls has been processed (blocks 412-416). For each de-queued RPCcall, the RPC dispatcher 395 is called to execute the call. The RPCdispatcher 395 executes the procedural call on behalf of the Mobile EndSystem 104, and formulates the Mobile End System response for those RPCcalls that require responses.

If, after exiting the loop, the queue still has work remaining (decisionblock 418), the queue will be marked as eligible to run again (block420). By existing the loop, the system yields the processor to the nextlower priority queue (blocks 424, 410). This ensures that all prioritylevels are given an opportunity to run no matter how much work exists inany particular queue. The system gets the next queue to service, anditerates the process until all queues have been processed. At the end ofprocessing all queues, the system tests to see if any queues have beenmarked as eligible to run—and if so, the association is scheduled to runagain by posting a schedule request to the global work queue. Theassociation is scheduled to run again in the “process global work”routine shown in FIG. 4 above. This approach yields the processor toallow other associations that have work to process an opportunity run.By assigning each queue a weight factor, the system may be tuned toallow different priority levels unequal access to the MobilityManagement Server 102's CPU. Thus, higher priority queues are not onlyexecuted first, but may also be tuned to allow greater access to theCPU.

Mobility Management Server RPC Responses

The discussion above relates explains how remote procedure calls aresent from the Mobile End System 104 to the Mobility Management Server102 for execution. In addition to this type of RPC call, the MobilityManagement Server 102 RPC engine 240′ also supports RPC events and RPCreceive responses. These are RPC messages that are generatedasynchronously as a result of association specific connection peeractivity (usually the Fixed End System 110). Mobility Management Server102 RPC engine 240′ completes RPC transactions that are executed by theRPC dispatcher 395. Not all RPC calls require a response on successfulcompletion. Those RPC calls that do require responses on successfulcompletion cause the RPC dispatcher 395 to build the appropriateresponse and post the response to the Internet Mobile Protocol engine244′ to be returned to the peer Mobile End System 104. All RPC callsgenerate a response when the RPC call fails (the RPC receive response isthe exception to above).

RPC events originate as a result of network 108 activity by theassociation specific connection (usually the [j1]Fixed End System 110).These RPC event messages are, in the preferred embodiment, proxied bythe Mobility Management Server 102 and forwarded to the Mobile EndSystem 104. The preferred embodiment Mobility Management Server 102supports the following RPC event calls:

-   -   Disconnect Event (this occurs when association-specific        connected peer (usually the Fixed End System 110) issues a        transport level disconnect request; the disconnect is received        by the proxy server 224 on behalf of the Mobile End System 104,        and the proxy server then transmits a disconnect event to the        Mobile End System);    -   Stream Receive Event (this event occurs when the        association-specific connected peer (usually the Fixed End        System 110) has sent stream data to the Mobile End System 104;        the proxy server 224 receives this data on behalf of the Mobile        End System 104, and sends the data to the Mobile End System in        the form of a Receive Response);    -   Receive Datagram Event (this event occurs when any        association-specific portal receives datagrams from a network        peer (usually the Fixed End System 110) destined for the Mobile        End System 104 through the Mobility Management Server 102; the        proxy server 224 accepts these datagrams on behalf of the Mobile        End System, and forwards them to the Mobile End System in the        form of receive datagram events; and    -   Connect Event (this event occurs when the association-specific        listening portal receives a transport layer connect request        (usually from the Fixed End System 110) when it wishes to        establish a transport layer end-to-end connection with a Mobile        End System 104; the proxy server 224 accepts the connect request        on behalf of the Mobile End System, and then builds a connect        event RPC call and forwards it to the Mobile End System).

FIG. 9 shows how the RPC engine 240′ handles proxy server-generated RPCcalls. For high priority address and connection objects, the RPC engine240′ dispatches a send request to the Internet Mobility Protocol engine244′ immediately. The send request results in forwarding the RPC messageto the peer Mobile End System 104. For lower priority objects, theInternet Mobility Protocol engine 244 send request is posted to anappropriate priority queue 510′. If the association is not scheduled torun, a schedule request is also posted to the global queue 358′. TheInternet Mobility Protocol send request is finally executed when thedispatch queues are processed as described earlier in connection withFIGS. 5 & 8.

Internet Mobility Protocol

Internet Mobility Protocol provided in accordance with an exampleembodiment of the present invention is a message oriented connectionbased protocol. It provides guaranteed delivery, (re)order detection,and loss recovery. Further, unlike other conventional connectionoriented protocols (i.e. TCP), it allows for multiple distinct streamsof data to be combined over a single channel; and allows for guaranteed,unreliable, as well as new message oriented reliable data to traversethe network through the single virtual channel simultaneously. This newmessage oriented level of service can alert the requester when theInternet Mobility Protocol peer has acknowledged a given program dataunit.

The Internet Mobility Protocol provided in accordance with a presentlypreferred exemplary embodiment of the present invention is designed tobe an overlay on existing network topologies and technologies. Due toits indifference to the underlying network architecture, it is transportagnostic. As long as there is a way for packetized data to traversebetween two peers, Internet Mobility Protocol can be deployed. Eachnode's network point of presence (POP) or network infrastructure canalso be changed without affecting the flow of data except where physicalboundary, policy or limitations of bandwidth apply.

With the help of the layer above, Internet Mobility Protocol coalescesdata from many sources and shuttles the data between the peers usingunderlying datagram facilities. As each discrete unit of data ispresented from the upper layer, Internet Mobility Protocol combines intoa single stream and subsequently submits it for transmission. The dataunits are then forwarded to the peer over the existing network whereupon reception, with the help from the layer above, the stream isdemultiplexed back into multiple distinct data units. This allows foroptimum use of available bandwidth, by generating the maximum sizednetwork frames possible for each new transmission. This also has theadded benefit of training the channel once for maximum bandwidthutilization and have its parameters applied to all session levelconnections.

In rare instances where one channel is insufficient, the InternetMobility Protocol further allows multiple channels to be establishedbetween the peers—thus allowing for data prioritization and possiblyproviding a guaranteed quality of service (if the underlying networkprovides the service).

The Internet Mobility Protocol also provides a dynamically selectableguaranteed or unreliable levels of service. For example, each protocoldata unit that is submitted for transmission can be queued with either avalidity time period or a number of retransmit attempts or both.Internet Mobility Protocol will expire a data unit when either thresholdis reached, and remove it from subsequent transmission attempts.

Internet Mobility Protocol's additional protocol overhead is keptminimal by use of a variable length header. The frame type and anyoptional fields determine the size of the header. These optional fieldsare added in a specific order to enable easy parsing by the receivingside and bits in the header flag field denote their presence. All othercontrol and configuration information necessary for the peers tocommunicate can be passed through the in-band control channel. Anycontrol information that needs to be sent is added to the frame prior toany application level protocol data unit. The receiving side processesthe control information and then passes the rest of the payload to theupper layer.

Designed to run over relatively unreliable network links where the errorprobability is relatively high, Internet Mobility Protocol utilizes anumber of techniques to insure data integrity and obtain optimum networkperformance. To insure data integrity, a Fletcher checksum algorithm isused to detect errant frames. This algorithm was selected due to thefact of its efficiency as well as its detection capability. It candetermine not only bit errors, but also bit reordering.

Sequence numbers are used to insure ordered delivery of data. InternetMobility Protocol sequence numbers do not, however, represent each byteof data as in TCP. They represent a frame of data that can be, in oneexample implementation, as large as 65535 bytes (including the InternetMobility Protocol header). They are 32 bits or other convenient lengthin one example to insure that wrap-around does not occur over highbandwidth links in a limited amount of time.

Combining this capability along with the expiration of data,retransmitted (retried) frames may contain less information than theprevious version that was generated by the transmitting side. A frame idis provided to enable detection of the latest versioned frame. However,since data is never added in the preferred embodiment and each elementremoved is an entire protocol data unit, this is not a necessity. In oneexample, the Internet Mobility Protocol will only process the firstinstance of a specific frame it receives—no matter how many otherversions of that frame are transmitted. Each frame created that carriesnew user payload is assigned its own unique sequence number.

Performance is gained by using of a sliding window technique—thusallowing for more then one frame to be outstanding (transmitted) at atime before requiring the peer to acknowledge reception of the data. Toinsure timely delivery of the data, a positive acknowledgement and timerbased retransmit scheme is used. To further optimize the use of thechannel, a selective acknowledgement mechanism is employed that allowsfor fast retransmission of missing frames and quick recovery duringlossy or congested periods of network connectivity. In one example, thisselective acknowledgement mechanism is represented by an optional bitfield that is included in the header.

A congestion avoidance algorithm is also included to allow the protocolto back off from rapid retransmission of frames. For example, a roundtrip time can be calculated for each frame that has successfullytransfer between the peers without a retransmit. This time value isaveraged and then used as the basis for the retransmission timeoutvalue. As each frame is sent, a timeout is established for that frame.If an acknowledgement for that frame is not received, and the frame hasactually been transmitted, the frame is resent. The timeout value isthen increased and then used as the basis for the next retransmissiontime. This retransmit time-out is bounded on both the upper and lowerside to insure that the value is within a reasonable range.

Internet Mobility Protocol also considers the send and receive pathsseparately. This is especially useful on channels that are asymmetric innature. Base on hysteresis, the Internet Mobility Protocol automaticallyadjusts parameters such as frame size (fragmentation threshold), numberof frames outstanding, retransmit time, and delayed acknowledgement timeto reduce the amount of duplicate data sent through the network.

Due to the fact that Internet Mobility Protocol allows a node to migrateto different points of attachment on diverse networks, characteristics(e.g., frame size) of the underlying network may change midstream. Anartifact of this migration is that frames that have been queued fortransmission on one network may no longer fit over the new medium themobile device is currently attached to. Combining this issue with thefact that fragmentation may not be supported by all networkinfrastructures, fragmentation is dealt with at the Internet MobilityProtocol level. Before each frame is submitted for transmission,Internet Mobility Protocol assesses whether or not it exceeds thecurrent fragmentation threshold. Note that this value may be less thanthe current maximum transmission unit for performance reason (smallerframes have a greater likelihood of reaching its ultimate destinationthen larger frames). The tradeoff between greater protocol overheadversus more retransmissions is weighed by Internet Mobility Protocol,and the frame size may be reduced in an attempt to reduce overallretransmissions). If a given frame will fit, it is sent in its entirety.If not, the frame is split into maximum allowable size for the givenconnection. If the frame is retransmitted, it is reassessed, and will berefragmented if the maximum transmission unit has been reduced (oralternatively, if the maximum transmission unit actually grew, the framemay be resent as a single frame without fragmentation).

The protocol itself is orthogonal in its design as either side mayestablish or terminate a connection to its peer. In a particularimplementation, however, there may be a few minor operationaldifferences in the protocol engine depending on where it is running. Forexample, based on where the protocol engine is running, certaininactivity detection and connection lifetime timeouts may be onlyinvoked on one side. To allow administrative control, Internet MobilityProtocol engine running on the Mobility Management Server 102 keepstrack of inactivity periods. If the specified period of time expireswithout any activity from the Mobile End System 104, the MobilityManagement Server 102 may terminate a session. Also, an administratormay want to limit the overall time a particular connection may beestablished for, or when to deny access base on time of day. Again thesepolicy timers may, in one example implementation, be invoked only on theMobility Management Server 102 side.

In one example implementation, the software providing the InternetMobility Protocol is compiled and executable under Windows NT, 9x, andCE environments with no platform specific modification. To accomplishthis, Internet Mobility Protocol employs the services of a networkabstraction layer (NAL) to send and receive Internet Mobility Protocolframes. Other standard utility functions such as memory management,queue and list management, event logging, alert system, powermanagement, security, etc are also used. A few runtime parameters aremodified depending on whether the engine is part of an Mobile End System104 or Mobility Management Server 102 system. Some examples of this are:

-   -   Certain timeouts are only invoked on the Mobility Management        Server 102    -   Direction of frames are indicated within each frame header for        echo detection    -   Inbound connections may be denied if Mobile End System 104 is so        configured    -   Alerts only signaled on Mobility Management Server 102    -   Power management enabled on Mobile End System 104 but is not        necessary on the Mobility Management Server 102

The Internet Mobility Protocol interface may have only a small number of“C” callable platform independent published API functions, and requiresone O/S specific function to schedule its work (other then theaforementioned standard utility functions). Communications with localclients is achieved through the use of defined work objects (workrequests). Efficient notification of the completion of each work elementis accomplished by signaling the requesting entity through the optionalcompletion callback routine specified as part of the work object.

The Internet Mobility Protocol engine itself is queue based. Workelements passed from local clients are placed on a global work queue inFIFO order. This is accomplished by local clients calling a publishedInternet Mobility protocol function such as “ProtocolRequestwork( )”. Ascheduling function inside of Internet Mobility Protocol then removesthe work and dispatches it to the appropriate function. Combining thequeuing and scheduling mechanisms conceal the differences betweenoperating system architectures—allowing the protocol engine to be rununder a threaded based scheme (e.g., Windows NT) or in a synchronousfashion (e.g., Microsoft Windows 9x & Windows CE). A priority scheme canbe overlaid on top of its queuing, thus enabling a guaranteed quality ofservice to be provided (if the underlying network supports it).

From the network perspective, the Internet Mobility Protocol usesscatter-gather techniques to reduce copying or movement of data. Eachtransmission is sent to the NAL as a list of fragments, and is coalescedby the network layer transport. If the transport protocol itselfsupports scatter-gather, the fragment list is passed through thetransport and assembled by the media access layer driver or hardware.Furthermore, this technique is extensible in that it allows theinsertion or deletion of any protocol wrapper at any level of theprotocol stack. Reception of a frame is signaled by the NAL layer bycalling back Internet Mobility Protocol at a specified entry point thatis designated during the NAL registration process.

Internet Mobility Protocol Engine Entry Points

Internet Mobility Protocol in the example embodiment exposes four commonentry points that control its startup and shutdown behavior. Theseprocedures are:

-   -   1. Internet Mobility ProtocolCreate( )    -   2. Internet Mobility ProtocolRun( )    -   3. Internet Mobility ProtocolHalt( )    -   4. Internet Mobility ProtocolUnload( )        Internet Mobility ProtocolCreate( )

The Internet Mobility ProtocolCreate( ) function is called by the bootsubsystem to initialize the Internet Mobility Protocol. During thisfirst phase, all resource necessary to start processing work must beacquired and initialized. At the completion of this phase, the enginemust be in a state ready to accept work from other layers of the system.At this point, Internet Mobility Protocol initializes a globalconfiguration table. To do this, it employs the services of theConfiguration Manager 228 to populate the table.

Next it registers its suspend and resume notification functions with theAPM handler. In one example, these functions are only invoked on theMobile End System 104 side—but in another implementation it might bedesirable to allow Mobility Management Server 102 to suspend duringoperations. Other working storage is then allocated from the memorypool, such as the global work queue, and the global NAL portal list.

To limit the maximum amount of runtime memory required as well asinsuring Internet Mobility Protocol handles are unique, InternetMobility Protocol utilizes a 2-tier array scheme for generating handles.The globalConnectionArray table is sized based on the maximum number ofsimultaneous connection the system is configured for, and allocated atthis time. Once all global storage is allocated and initialized, theglobal Internet Mobility Protocol state is change to _STATE_INITIALIZE_.

Internet Mobility ProtocolRun( )

The Internet Mobility ProtocolRun( ) function is called after allsubsystems have been initialized, and to alert the Internet MobilityProtocol subsystem that it is okay to start processing any queued work.This is the normal state that the Internet Mobility Protocol engine isduring general operations. A few second pass initialization steps aretaken at this point before placing the engine into an operational state.

Internet Mobility Protocol allows for network communications to occurover any arbitrary interface(s). During the initialization step, thestorage for the interface between Internet Mobility Protocol and NAL wasallocated. Internet Mobility Protocol now walks through the globalportal list to start all listeners at the NAL. In one example, this iscomprised of a two step process:

-   -   Internet Mobility Protocol requests the NAL layer to bind and        open the portal based on configuration supplied during        initialization time; and    -   Internet Mobility Protocol then notifies the NAL layer that it        is ready to start processing received frames by registering the        Internet Mobility ProtocolRCVFROMCB call back.    -   A local persistent identifier (PID) is then initialized.

The global Internet Mobility Protocol state is change to _STATE_RUN_.

Internet Mobility ProtocolHalt

The Internet Mobility ProtocolHalt( ) function is called to alert theengine that the system is shutting down. All resources acquired duringits operation are to be release prior to returning from this function.All Internet Mobility Protocol sessions are abnormally terminated withthe reason code set to administrative. No further work is accepted fromor posted to other layers once the engine has entered into_STATE_HALTED_state.

Internet Mobility ProtocolUnload( )

The Internet Mobility ProtocolUnload( ) function is the second phase ofthe shutdown process. This is a last chance for engine to release anyallocated system resources still being held before returning. Once theengine has returned from this function, no further work will be executedas the system itself is terminating

Internet Mobility Protocol Handles

In at least some examples, using just the address of the memory (whichcontains the Internet Mobility Protocol state information) as the tokento describe an Internet Mobility Protocol connection may beinsufficient. This is mainly due to possibility of one connectionterminating and a new one starting in a short period of time. Theprobability that the memory allocator will reassign the same address fordifferent connections is high—and this value would then denote both theold connection and a new connection. If the original peer did not hearthe termination of the session (i.e. it was off, suspended, out ofrange, etc.), it could possibly send a frame on the old session to thenew connection. This happens in TCP and will cause a reset to begenerated to the new session if the peer's IP addresses are the same. Toavoid this scenario, Internet Mobility Protocol uses manufacturedhandle. The handles are made up of indexes into two arrays and a noncefor uniqueness. The tables are laid out as follows.

Table 1: an array of pointers to an array of connection object.

Table 2: an array of connection objects that contains the real pointersto the Internet Mobility Protocol control blocks.

This technique minimizes the amount of memory being allocated atinitialization time. Table 1 is sized and allocated at startup. On theMobile End System 104 side this allows allocation of a small amount ofmemory (the memory allocation required for this Table 1 on the MobilityManagement Server 102 side is somewhat larger since the server can havemany connections).

Table 1 is then populated on demand. When a connection request isissued, Internet Mobility Protocol searches through Table 1 to find avalid pointer to Table 2. If no entries are found, then InternetMobility Protocol will allocate a new Table 2 with a maximum of 256connection objects—and then stores the pointer to Table 2 into theappropriate slot in Table 1. The protocol engine then initializes Table2, allocates a connection object from the newly created table, andreturns the manufactured handle. If another session is requested,Internet Mobility Protocol will search Table 1 once again, find thevalid pointer to Table 2, and allocate the next connection object forthe session. This goes on until one of two situations exist:

-   -   If all the connection objects are exhausted in Table 2, a new        Table 2 will be allocated, initialized, and a pointer to it will        be placed in the next available slot in Table 1; and    -   If all connection objects have been released for a specific        Table 2 instance and all elements are unused for a specified        period of time, the storage for that instance of Table 2 is        released back to the memory pool and the associated pointer in        Table 1 is zeroed to indicate that that entry is now available        for use when the next connection request is started (if and only        if no other connection object are available in other instances        of Table 2).

Two global counters are maintained to allow limiting the total number ofconnections allocated. One global counter counts the number of currentactive connections; and the other keeps track of the number ofunallocated connection objects. The second counter is used to govern thetotal number of connection object that can be created to some arbitrarylimit. When a new Table 2 is allocated, this counter is adjusteddownward to account for the number of objects the newly allocated tablerepresents. On the flip side, when Internet Mobility Protocol releases aTable 2 instance back to the memory pool, the counter is adjusted upwardwith the number of connection objects that are being released.

Work Flow

Work is requested by local clients through the Internet MobilityProtocolRequestWork( ) function. Once the work is validated and placedon the global work queue, the Internet MobilityProtocolWorkQueueEligible( ) function is invoked. If in a threadedenvironment, the Internet Mobility Protocol worker thread is signaled(marked eligible) and control is immediately returned to the callingentity. If in a synchronous environment, the global work queue isimmediately run to process any work that was requested. Both methods endup executing the Internet Mobility ProtocolProcessWork( ) function. Thisis the main dispatching function for processing work.

Since only one thread at a time may be dispatching work from the globalqueue in the example embodiment, a global semaphore may be used toprotect against reentrancy. Private Internet Mobility Protocol work canpost work directly to the global work queue instead of using theInternet Mobility ProtocolRequestWork( ) function.

A special case exists for SEND type work objects. To insure that thesemantics of Unreliable Datagrams is kept, each SEND type work objectcan be queued with an expiry time or with a retry count. Work will beaged based on the expiry time. If the specified timeout occurs, the workobject is removed from the connection specific queue, and is completedwith an error status. If the SEND object has already been coalesced intothe data path, the protocol allows for the removal of any SEND objectthat has specified a retry count. Once the retry count has beenexceeded, the object is removed from the list of elements that make upthe specific frame, and then returned to the requester with theappropriate error status.

Connection Startup

Internet Mobility Protocol includes a very efficient mechanism toestablish connections between peers. Confirmation of a connection can bedetermined in as little as a three-frame exchange between peers. Theinitiator sends an IMP SYNC frame to alert its peer that it isrequesting the establishment of a connection. The acceptor will eithersend an IMP ESTABLISH frame to confirm acceptance of the connection, orsend an IMP ABORT frame to alert the peer that its connection requesthas been rejected. Reason and status codes are passed in the IMP ABORTframe to aid the user in decipher the reason for the rejection. If theconnection was accepted, an acknowledgement frame is sent (possiblyincluding protocol data unit or control data) and is forwarded to theacceptor to acknowledge receipt of its establish frame.

To further minimize network traffic, the protocol allows user andcontrol data to be included in the initial handshake-mechanism used atconnection startup. This ability can be used in an insecure environmentor in environments where security is dealt with by a layer below, suchthat the Internet Mobility Protocol can be tailored to avert theperformance penalties due to double security authentication andencryption processing being done over the same data path.

Data Transfer

Internet Mobility Protocol relies on signaling from the NAL to detectwhen a frame has been delivered to the network. It uses this metric todetermine if the network link in question has been momentarily flowcontrolled, and will not submit the same frame for retransmission untilthe original request has been completed. Some network drivers howeverlie about the transmission of frames and indicate delivery prior tosubmitting them to the network. Through the use of semaphores, theInternet Mobility Protocol layer detects this behavior and only willsend another datagram until the NAL returns from the original sendrequest

Once a frame is received by Internet Mobility Protocol, the frame isquickly validated, then placed on an appropriate connection queue. Ifthe frame does not contain enough information for Internet MobilityProtocol to discern its ultimate destination, the frame is placed on theInternet Mobility Protocol socket queue it frame was received on, andthen that socket queue is place on the global work queue for subsequenceprocessing. This initial demultiplexing allows received work to bedispersed rapidly with limited processing overhead.

Acquiescing

To insure minimal use of network bandwidth during periods ofretransmission and processing power on the Mobility Management Server102, the protocol allows the Mobility Management Server 102 to“acquiesce” a connection. After a user configurable period of time, theMobility Management Server 102 will stop retransmitting frames for aparticular connection if it receives no notification from thecorresponding Mobile End System 104. At this point, the MobilityManagement Server 102 assumes that the Mobile End System 104 is in someunreachable state (i.e. out of range, suspended, etc), and places theconnection into a dormant state. Any further work destined for thisparticular connection is stored for future delivery. The connection willremain in this state until one of the following conditions are met:

-   -   Mobility Management Server 102 receives a frame from the Mobile        End System 104, thus returning the connection to its original        state;    -   a lifetime timeout has expired;    -   an inactivity timeout has expired; or    -   the connection is aborted by the system administrator.

In the case that the Mobility Management Server 102 receives a framefrom the Mobile End System 104, the connection continues from the pointit was interrupted. Any work that was queued for the specific connectionwill be forwarded, and the state will be resynchronized. In any of theother cases, the Mobile End System 104 will be apprised of thetermination of the connection once it reconnects; and work that wasqueued for the Mobile End System 104 will be discarded.

Connect and Send Requests

FIGS. 10A-10C together are a flowchart of example connect and sendrequest logic formed by Internet mobility engine 244. In response toreceipt from a command from RPC engine 240, the Internet MobilityProtocol engine 244 determines whether the command is a “connect”request (decision block 602). If it is, engine 244 determines whetherconnection resources can be allocated (decision block 603). If it is notpossible to allocate sufficient connection resources (“no” exit todecision block 603), engine 244 declares an error (block 603 a) andreturns. Otherwise, engine 244 performs a state configuration process inpreparation for handling the connect request (block 603 b).

For connect and other requests, engine 244 queues the connect or sendrequest and signals a global event before return to the callingapplication (block 604).

To dispatch a connect or send request from the Internet MobilityProtocol global request queue, engine 244 first determines whether anywork is pending (decision block 605). If no work is pending (“no” exitto decision block 605), engine 244 waits for the application to queuework for the connection by going to FIG. 10C, block 625 (block 605 a).If there is work pending (“yes” exit to decision block 605), engine 244determines whether the current state has been established (block 606).If the state establish has been achieved (“yes” exit to decision block606), engine 244 can skip steps used to transition into establish stateand jump to decision block 615 of FIG. 10B (block 606 a). Otherwise,engine 244 must perform a sequence of steps to enter establish state(“no” exit to decision block 606).

In order to enter establish state, engine 244 first determines whetherthe address of its peer is known (decision block 607). If not, engine244 waits for the peer address while continuing to queue work andtransitions to FIG. 10C block 625 (block 607 a). If the peer address isknown (“yes” exit to decision block 607), engine 244 next tests whetherthe requisite security context has been acquired (decision block 608).If not, engine 244 must wait for the security context while continuingto queue work and transitioning to block 625 (block 608 a). If securitycontext has already been acquired (“yes” exit to decision block 608),engine 244 declares a “state pending” state (block 608 b), and thensends an Internet Mobility Protocol sync frame (block 609) and starts aretransmit timer (block 610). Engine 244 determines whether thecorresponding established frame was received (block 611). If it was not(“no” exit to decision block 611), engine 244 tests whether theretransmit time has expired (decision block 612). If the decision blockhas not expired (“no” exit to decision block 612), engine 244 waits andmay go to step 625 (block 613). Eventually, if the established frame isnever received (as tested for by block 611) and a total retransmit timeexpires (decision block 614), the connection may be aborted (block 614a). If the established is eventually received (“yes” exit to decisionblock 611), engine 244 declares a “state established” state (block 611a).

Once state establish has been achieved, engine 244 tests whether the newconnection has been authenticated (decision block 615). If it has notbeen, engine 244 may wait and transition to step 625 (block 616). If theconnection has been authenticated (“yes” exit to decision block 615),engine 244 tests whether authentication succeeded (decision block 617).If it did not (“no” exit to decision block 617), the connection isaborted (block 614 a). Otherwise, engine 244 tests whether the peertransmit window is full (decision block 618). If it is (“yes” exit todecision block 618), engine 244 waits for acknowledgment and goes tostep 625 (decision block 619). If the window is not full (“no” exit todecision block 618), engine 244 creates an Internet Mobility Protocoldata frame (block 620) and sends it (block 621). Engine 244 thendetermines if the retransmit timer has started (decision block 622). Ifno, engine 244 starts the retransmit timer (block 623). Engine 244 loopsthrough blocks 618-623 until there is no more data to send (as testedfor by decision block 624). Engine 244 then returns to a sleep modewaiting for more work and returns to the global dispatcher (block 625).

Termination

FIG. 11 is a flowchart of example steps performed by Internet MobilityProtocol engine 244 to terminate a connection. In response to a“terminate connection” request (block 626), the engine queues therequest to its global work queue and returns to the calling application(block 626 a). The terminate request is eventually dispatched from theInternet Mobility Protocol process global work queue for execution(block 627). Engine 244 examines the terminate request and determineswhether the terminate request should be immediate or graceful (decisionblock 628). If immediate (“abort” exit to decision block 628), engine244 immediately aborts the connection (block 629). If graceful(“graceful” exit to decision block 628), engine 244 declares a “stateclose” state (block 628 a), and sends an Internet Mobility Protocol“Mortis” frame (block 630) to indicate to the peer that the connectionis to close. Engine 244 then declares a “Mortis” state (block 630 a) andstarts the retransmit timer (block 631). Engine 244 tests whether theresponse of “post mortem” frame has been received from the peer(decision block 632). If not (“no” exit to decision block 632), engine244 determines whether a retransmit timer has yet expired (decisionblock 633). If the retransmit timer is not expired (“no” exit todecision block 633), engine 244 waits and proceeds to step 637 (block634). If the retransmit timer has expired (“yes” exit to decision block633), engine 244 determines whether the total retransmit time hasexpired (decision block 635). If the total time is not yet expired (“no”exit to decision block 635), control returns to block 630 to resent theMortis frame. If the total retransmit time has expired (“yes” exit todecision block 635), engine 244 immediately aborts the connection (block635 a).

Once a “post mortem” responsive frame has been received from the peer(“yes” exit to decision block 632), engine 244 declares a “post mortem”state (block 632 a), releases connection resources (block 636), andreturns to sleep waiting for more work (block 637).

Retransmission

FIG. 12 is a flowchart of example “retransmit” events logic performed byInternet Mobility Protocol engine 244. In the event that the retransmittimer has expired (block 650), engine 244 determines whether any framesare outstanding (decision block 651). If no frames are outstanding (“no”exit to decision block 651), engine 244 dismisses the timer (block 652)and returns to sleep (block 660). If, on the other hand, frames areoutstanding (“yes” exit to decision block 651), engine 244 determineswhether the entire retransmit period has expired (decision block 653).If it has not (“no” exit to decision block 653), the process returns tosleep for the difference in time (block 654). If the entire retransmittime period has expired (“yes” exit to decision block 653), engine 244determines whether a total retransmit period has expired (decision block655). If it has (“yes” exit to decision block 655) and this event hasoccurred in the Mobility Management Server engine 244′ (as opposed tothe Mobile End System engine 244), a dormant state is declared (decisionblock 656, block 656 a). Under these same conditions, the InternetMobility Protocol engine 244 executing on the Mobile End System 104 willabort the connection (block 656 b).

If the total retransmit period is not yet expired (“no” exit to decisionblock 655), engine 244 reprocesses the frame to remove any expired data(block 657) and then retransmits it (block 658)—restarting theretransmit timer as it does so (block 659). The process then returns tosleep (block 660) to wait for the next event.

Internet Mobility Protocol Expiration of a PDU

FIG. 12 block 657 allows for the requesting upper layer interface tospecify a timeout or retry count for expiration of any protocol dataunit (i.e. a SEND work request) submitted for transmission to theassociated peer. By use of this functionality, Internet MobilityProtocol engine 244 maintains the semantics of unreliable data andprovides other capabilities such as unreliable data removal fromretransmitted frames. Each PDU (protocol data unit) 506 submitted by thelayer above can specify a validity timeout and/or retry count for eachindividual element that will eventually be coalesced by the InternetMobility Protocol engine 244. The validity timeout and/or retry count(which can be user-specified for some applications) are used todetermine which PDUs 506 should not be retransmitted but should insteadbe removed from a frame prior to retransmission by engine 244.

The validity period associated with a PDU 506 specifies the relativetime period that the respective PDU should be considered fortransmission. During submission, the Internet Mobility ProtocolRequestWork function checks the expiry timeout value. If it is non-zero,an age timer is initialized. The requested data is then queued on thesame queue as all other data being forwarded to the associated peer. Ifthe given PDU 506 remains on the queue for longer than the time periodspecified by the validity period parameter, during the next event thatthe queue is processed, the a status code of “timeout failure” ratherthan being retransmitted when the frame is next retransmitted. Thisalgorithm ensures that unreliable data being queued for transmission tothe peer will not grow stale and/or boundlessly consume systemresources.

In the example shown in FIG. 12A, three separate PDUs 506 are queued toInternet Mobility Protocol engine 244 for subsequent processing. PDU506(1) is queued without an expiry time denoting no timeout for thegiven request. PDU 506(2) is specified with a validity period of 2seconds and is chronologically queued after PDU 506(1). PDU 506(n) isqueued 2.5 seconds after PDU 506(2) was queued. Since the act of queuingPDU 506(n) is the first event causing processing of the queue and PDU506(2) expiry time has lapsed, PDU 506(2) is removed from the workqueue, completed locally and then PDU 506(n), is placed on the list. Ifa validity period was specified for PDU 506(n) the previous sequence ofevents would be repeated. Any event (queuing, dequeuing, etc) thatmanipulates the work queue will cause stale PDUs to be removed andcompleted.

As described above, PDUs 506 are coalesced by the Internet MobilityProtocol Engine 244 transmit logic and formatted into a single datastream. Each discrete work element, if not previously expired by thevalidity timeout, is gathered to formulate Internet Mobility Protocoldata frames. Internet Mobility Protocol Engine 244 ultimately sendsthese PDUs 506 to the peer, and then places the associated frame on aFrames-Outstanding list. If the peer does not acknowledge the respectiveframe in a predetermined amount of time (see FIG. 12 showing theretransmission algorithm), the frame is retransmitted to recover frompossibly a lost or corrupted packet exchange. Just prior toretransmission, the PDU list that the frame is comprised of is iteratedthrough to determine if any requests were queued with a retry count. Ifthe retry count is non zero, and the value is decremented to zero, thePDU 506 is removed from the list, and the frames header is adjusted todenote the deletion of data. In this fashion, stale data, unreliabledata, or applications employing their own retransmission policy are notburdened by engine 244's retransmission algorithm.

In the FIG. 12B example, again three separate PDUs 506 are queued toInternet Mobility Protocol engine 244 for subsequent processing. PDU506(1) is queued without a retry count. This denotes continuousretransmission attempts or guaranteed delivery level of service. PDU506(2) is queued with a retry count of 1 and is chronologically queuedafter PDU 506(1). PDU 506(n) is queued sometime after PDU 506(2). Atthis point, some external event (e.g., upper layer coalesce timer, etc.)causes engine 244's send logic to generate a new frame by gatheringenough PDUs 506 from the work queue to generate an Internet MobilityProtocol data frame 500. The frame header 503 is calculated and stampedwith a retry ID of 0 to denote that this is the first transmission ofthe frame. The frame is then handed to the NAL layer for subsequenttransmission to the network. At this point a retransmit timer is startedsince the frame in question contains a payload. For illustrationpurposes it is assumed that an acknowledgement is not received from thepeer for a variety of possible reasons before the retransmit timerexpires. The retransmit logic of engine 244 determines that the frame500 in question is now eligible for retransmission to the network. Priorto resubmitting the frame to the NAL layer, engine 244's retransmitlogic iterates through the associated list of PDUs 506. Each PDU's retrycount is examined and if non-zero, the count is decremented. In theprocess of decrementing PDU 506(2)'s retry count, the retry countbecomes zero. Because PDU 506(2)'s retry count has gone to zero, it isremoved from the list and completed locally with a status of “retryfailure.” The frame header 503 size is then adjusted to denote theabsence of the PDU 506(2)'s data. This process is repeated for allremaining PDUs. Once the entire frame 500 is reprocessed to produce an“edited” frame 500′, the retry ID in the header is incremented and theresultant datagram is then handed to the NAL layer for subsequent(re)transmission.

Reception

FIGS. 13A-13D are a flowchart of example steps performed by InternetMobility Protocol engine 244 in response to receipt of a “receive”event. Such receive events are generated when an Internet MobilityProtocol frame has been received from network 108. In response to thisreceive event, engine 244 pre-validates the event (block 670) and testswhether it is a possible Internet Mobility Protocol frame (decisionblock 671). If engine 244 determines that the received frame is not apossible frame (“no” exit to decision block 671), it discards the frame(block 672). Otherwise (“yes” exit to decision block 671), engine 244determines whether there is a connection associated with the receivedframe (decision block 673). If there is a connection associated with thereceived frame (“yes” exit to decision block 673), engine 244 places thework on the connection receive queue (block 674), marks the connectionas eligible to receive (block 675), and places the connection on theglobal work queue (block 676). If no connection has yet been associatedwith the received frame (“no” exit to decision block 673), engine 244places the received frame on the socket receive queue (block 677) andplaces the socket receive queue on the global work queue (block 678). Ineither case, engine 244 signals a global work event (block 679). Upondispatching of a “receive eligible” event from the global work queue(see FIG. 13B), engine 244 de-queues the frame from the respectivereceive queue (block 680). It is possible that more then one IMP frameis received and queued before the Internet Mobility Protocol engine 244can start de-queuing the messages. Engine 244 loops until all frameshave been de-queue (blocks 681, 682). Once a frame has been de-queued(“yes” exit to decision block 681), engine 244 validates the receivedframe (block 683) and determines whether it is okay (decision block684). If the received frame is invalid, engine 244 discards it (block685) and de-queues the next frame from the receive queue (block 680). Ifthe received frame is valid (“yes” exit to decision block 684), engine244 determines whether it is associated with an existing connection(block 686). If it is not (“no” exit to decision block 686), engine 244tests whether it is a sync frame (decision block 687). If it is not async frame (“no” exit to decision block 687), the frame is discarded(block 685). If, on the other hand, a sync frame has been received(“yes” exit to decision block 687), engine-244 processes it using apassive connection request discussed in association with FIGS. 14A and14B (block 688).

If the frame is associated with a connection (“yes” exit to decisionblock 686), engine 244 determines whether the connection state is stillactive and not “post mortem” (decision block 689). If the connection isalready “post mortem,” the frame is discarded (block 685). Otherwise,engine 244 parses the frame (block 690) and determines whether it is anabort frame (decision block 691). If the frame is an abort frame, engine244 immediately aborts the connection (block 691 a). If the frame is notan abort frame (“yes” exit to decision block 691), engine 244 processesacknowledgment information and releases any outstanding send frames(block 692). Engine 244 then posts the frame to any security subsystemfor possible decryption (block 693). Once the frame is returned from thesecurity subsystem engine 244 processes any control data (block 694).Engine 244 then determines whether the frame contains application data(decision block 695). If it does, this data is queued to the applicationlayer (block 696). Engine 244 also determines whether the connection'sstate is dormant (block 697 and 697 a—this can happen on MobilityManagement Server engine 244′ in the preferred embodiment), and returnsstate back to established.

If the frame is possibly a “Mortis” frame (“yes” exit to decision block698), engine 244 indicates a “disconnect” to the application layer(block 699) and enters the “Mortis” state (block 699 a). It sends a“post mortem” frame to the peer (block 700), and enters the “postmortem” state (block 700 a). Engine 244 then releases connectionresources (block 701) and returns to sleep waiting for more work (block702). If the parsed frame is a “post mortem” frame (“yes” exit todecision block 703), blocks 700 a, 701, 702 are executed. Otherwise,control returns to block 680 to dequeue the next frame from the receivequeue (block 704).

Passive Connections

Blocks 14A-14B are together a flowchart of example steps performed byInternet Mobility Protocol engine 244 in response to a “passiveconnection” request. Engine 244 first determines whether there isanother connection for this particular device (block 720). If there is(“yes” exit to decision block 720), the engine determines whether it isthe initial connection (decision block 721). If peer believes the newconnection is the initial connection (“yes” exit to decision block 721),engine 244 aborts the previous connections (block 722). If not theinitial connection (“no” exit to decision block 721), engine 244 testswhether the sequence and connection ID match (decision block 723). Ifthey do not match (“no” exit to decision block 723), control returns todecision block 720. If the sequence and connection ID do match (“yes”exit to decision block 723), engine 244 discards duplicate frames (block724) and returns to step 680 of FIG. 13B (block 725).

If there is no other connection (“no” exit to decision block 720),engine 244 determines whether it can allocate connection resources forthe connection (decision block 726). If it cannot, an error is declared(“no” exit to decision block 726, block 727), and the connection isaborted (block 728). If it is possible to allocate connection resources(“yes” exit to decision block 726), engine 244 declares a “configure”state (block 726 a) and acquires the security context for the connection(block 730). If it was not possible to acquire sufficient securitycontext (“no” exit to decision block 731), the connection is aborted(block 728). Otherwise, engine 244 sends an established frame (block732) and declares the connection to be in state “establish” (block 732a). Engine 244 then starts a retransmitter (block 733) and waits for theauthentication process to conclude (block 734). Eventually, engine 244tests whether the device and user have both been authenticated (block735). If either the device or the user is not authenticated, theconnection is aborted (block 736). Otherwise, engine 244 indicates theconnection to the listening application (block 737) and gets theconfiguration (block 738). If either of these steps do not succeed, theconnection is aborted (decision block 739, block 740). Otherwise, theprocess returns to sleep waiting for more work (block 741).

Abnormal Termination

FIGS. 15A and 15B are a flowchart of example steps performed by theInternet Mobility Protocol engine 244 in response to an “abort”connection request. Upon receipt of such a request from another process(block 999) and are dispatched via the queue (block 1000), engine 244determines whether the connection is associated with the request(decision block 1001). If it is (“yes” exit to decision block 1001),engine 244 saves the original state (block 1002) and declares an “abort”state (block 1002 a). Engine 244 then determines whether the connectionwas indicated to any listening application (decision block 1003)—and ifso, indicates a disconnect to that listening application (block 1004).Engine 244 then declares a “post mortem” state (block 1003 a), releasesthe resources previously allocated to the particular connection (block1005), and tests whether the original state is greater than the statepending (decision block 1006). If not (“no” exit to decision block1006), the process transitions to block 1002 to return to the callingroutine (block 1007). Otherwise, engine 244 determines whether therequest is associated with a received frame (decision block 1008). Ifthe abort request is associated with a received frame, and the receivedframe is an abort frame (decision block 1009), the received frame isdiscarded (block 1010). Otherwise engine 244 will send an abort frame(block 1011) before returning to the calling routine (block 1012).

Roaming Control

Referring once again to FIG. 1, mobile network 108 may comprise a numberof different segments providing different network interconnects (107a-107 k corresponding to different wireless transceivers 106 a-106 k).In accordance with another aspect of a presently preferred exemplaryembodiment of the present invention, network 108 including MobilityManagement Server 102 is able to gracefully handle a “roaming” conditionin which a Mobile End System 104 has moved from one network interconnectto another. Commonly, network 108 topographies are divided into segments(subnets) for management and other purposes. These different segmentstypically assign different network (transport) addresses to the variousMobile End Systems 104 within the given segment.

It is common to use a Dynamic Host Configuration Protocol (DHCP) toautomatically configure network devices that are newly activated on sucha subnet. For example, a DHCP server on the sub-net typically providesits clients with (among other things) a valid network address to“lease”. DHCP clients may not have permanently assigned, “hard coded”network addresses. Instead, at boot time, the DHCP client requests anetwork address from the DHCP server. The DHCP server has a pool ofnetwork addresses that are available for assignment. When a DHCP clientrequests an network address, the DHCP server assigns, or leases, anavailable address from that pool to the client. The assigned networkaddress is then “owned” by the client for a specified period (“leaseduration”). When the lease expires, the network address is returned tothe pool and becomes available for reassignment to another client. Inaddition to automatically assigning network addresses, DHCP alsoprovides netmasks and other configuration information to clients runningDHCP client software. More information concerning the standard DHCPprotocol can be found in RFC2131.

Thus, when a Mobile End System 104 using DHCP roams from one subnet toanother, it will appear with a new network address. In accordance with apresently preferred exemplary embodiment of the present invention,Mobile End Systems 104 and Mobility Management Server 102 take advantageof the automatic configuration functionality of DHCP, and coordinatetogether to ensure that the Mobility Management Server recognizes theMobile End System's “new ” network address and associates it with thepreviously established connection the Mobility Management Server isproxying on its behalf.

The preferred embodiment uses standard DHCP Discover/Offer client-serverbroadcast messaging sequences as an echo request-response, along withother standard methodologies in order to determine if a Mobile EndSystem 104 has roamed to a new subnet or is out of range. In accordancewith the standard DHCP protocol, a Mobile End System 104 requiring anetwork address will periodically broadcast client identifier andhardware address as part of a DHCP Discover message. The DHCP serverwill broadcast its Offer response (this message is broadcast rather thantransmitted specifically to the requesting Mobile End System because theMobile End System doesn't yet have a network address to send to). Thus,any Mobile End System 104 on the particular subnet will pick up any DHCPOffer server response to any other Mobile End System broadcast on thesame subnet.

A presently preferred exemplary embodiment of present invention providesDHCP listeners to monitor the DHCP broadcast messages and therebyascertain whether a particular Mobile End System 104 has roamed from onesubnet to another and is being offered the ability to acquire a newnetwork address by DHCP. FIG. 16 shows example DHCP listener datastructures. For example, a Mobile End System listener data structure 902may comprise:

-   -   a linked list of server data structures,    -   an integer transaction ID number (xid),    -   a counter (“ping”), and    -   a timeout value.        A server data structure 904 may comprise a linked list of data        blocks each defining a different DHCP server, each data block        comprising:    -   a pointer to next server,    -   a server ID (network address of a DHCP server),    -   an address (giaddr) of a BOOTP relay agent recently associated        with this DHCP server,    -   a “ping” value (socket−>ping), and    -   a flag.

These data-structures are continually updated based on DHCP broadcasttraffic appearing on network 108. The following example functions can beused to maintain these data structures:

-   -   roamCreate( ) [initialize variables]    -   roamDeinitialize( ) [delete all listeners]    -   roamStartIndications( ) [call a supplied callback routine when a        Mobile End System has roamed or changed interfaces, to give a        registrant roaming indications]    -   roamStopIndications( ) [remove the appropriate callback from the        list, to stop giving a registrant roaming indications]    -   Interface Change [callback notification from operating system        indicating an interface has changed its network address]    -   Listener Signal [per-interface callback from a Listener        indicating a roaming or out-of-range or back-in-range        condition].

Additionally, a refresh process may be used to update Listeners afterinterface changes.

In the preferred embodiment, all Mobile End Systems 104 transmit thesame Client Identifier and Hardware Address in DHCP Discover requests.This allows the listener data structures and associated processes todistinguish Mobile End System-originated Discover requests from Discoverrequests initiated by other network devices. Likewise, the DHCP serverwill broadcast its response, so any Mobile End System 104 and/or theMobility Management Server 102 will be able to pick up the DHCP serverOffer response to any other Mobile End System. Since multiple DHCPservers can respond to a single DHCP Discover message, the listener datastructures shown in FIG. 16 store each server response in a separatedata block, tied to the main handle via linked list.

Upon receiving a Discover request having the predetermined ClientHardware Address and Client Identifier, the preferred embodimentrecognizes this request as coming from a Mobile End System 104. If themessage also has a BOOTP relay address set to zero, this indicates thatthe message originated on the same subnet as the listener. Listeners mayignore all DHCP Offers unless they have a transaction ID (xid) matchingthat of a Discover message recently sent by a Mobile End System 104. Thelistener can determine that a Mobile End System 104 has roamed if anyresponse comes from a known server with a new BOOTP relay agent IDand/or offered network address masked with an offered subnet mask.Listeners add new servers to the FIG. 16 data structures only afterreceiving a positive response from an old server. If a listener receivesresponses from new server(s) but none from an old server, this mayindicate roaming (this can be a configurable option). If the listenerfails to receive responses from new or old servers, the listener is outof range (this determination can be used to signal an upper layer suchas an application to halt or reduce sending of data to avoid bufferoverflow).

If the listener never receives a response from any server, there is nopoint of reference and thus impossible to determine whether roaming hasoccurred. This condition can be handled by signaling an error after atimeout and allowing the caller to retry the process. The preferredembodiment determines that a Mobile End System 104 has roamed if anyresponse has come from a known server with a new BOOTP relay agent ID(or a new offered network address when masked with offered subnet mask).If the listener data structures see responses from new servers but nonefrom an old server, it is possible that roaming has occurred, but theremust be a delay before signaling, in order to wait for any potentialresponses from the old servers. If there are no responses from new orold servers, then the Mobile End System 104 is probably out of range andMobility Management Server 102 waits for it to come back into range.

FIG. 17 is a flowchart of example steps of a Listener process of thepreferred embodiment. Referring to FIG. 17, a DHCP listener process iscreated by allocating appropriate memory for the handle, opening NALsockets for the DHCP client and server UDP ports, and setting receivecallbacks for both. A timer is then set (block 802) and then the processenters the “Wait” state to wait for a roaming related event (block 804).Three external inputs can trigger an event:

-   -   a DHCP server packet is received;    -   a DHCP client packet sent by another Mobile End System is        received    -   a timer timeout occurs.

If a DHCP server packet has been received, the packet is examined todetermine whether its client identifier matches the predetermined clientID (decision block 806). If it does not, it is discarded. However, ifthe packet does contain the predetermined ID, a test is performed todetermine whether the packet is a DHCP Offer packet (decision block808). Offer packets are rejected unless they contain a transaction IDmatching a recently sent DHCP Discover sequence.

If the packet transaction ID matches (block 810), then a test is made asto whether the server sending the DHCP offer packet is known (i.e., theserver ID is in the listener data structure shown in FIG. 16) (block812). If the server ID is not on the list (“no” exit to decision block812), it is added to the list and marked as “new” (or “first” if it isthe first server on the list) (block 822). If the server is already onthe list (“Y” exit to decision block 812), a further test is performedto determine whether the packet BOOTP relay address (“GIADDR”) matchesthe server address (“GIADDR”) (decision block 814). If there is nomatch, then the Offer packet must be originating from a differentsubnet, and it is determined that a “hard roam” has occurred (block816). The caller application is signaled that there has been a roam. If,on the other hand, decision block 814 determines there is a match inBOOTP relay addresses, then no roam has occurred, the listener processstamps the server receive time, resets “new” flags for all other serverson the list, and stores the current ping number with the server (block818, 820). The process then returns to “wait” period.

If the event is a received client packet, the listener processdetermines whether the packet has the predetermined client ID, is a DHCPDiscover packet and has a BOOTP relay address (GIADDR) of 0 (blocks 824,826, 828). These steps determine whether the received packet is DHCPDiscover message sent by another Mobile End System 104 on the samesub-net as the listener. If so, the listener process then sets thetransaction ID to the peer's transaction ID (block 830) for use incomparing with later-received DHCP Offer packets, calls a ping check(block 834) and resets the timer (block 836).

In response to a timer timeout, the process calls a “ping check” (block838). “Pings” in the preferred embodiment are DHCP Discover packets witha random new xid. Example steps for this ping check 838 are shown inFIG. 17A. The purpose of the ping check routine is to determine if a“soft roam” condition has occurred (i.e., a Mobile End System hastemporarily lost and then regained contact with a sub-net, but has notroamed to a different sub-net). The process determines whether there isa sub-net roam condition, an out-of-range condition, or a “no server”condition. In other words:

-   -   Has a Mobile End System roamed from one sub-net to another?    -   Is a Mobile End System out of range?    -   Is a DHCP server absent?

These conditions are determined by comparing Mobile End System prior“ping” response with the current “ping” response (decision blocks 846,850). For example, if the current ping number minus the old server'slast ping response is greater than the sub-net server pings and there isat least one server marked “new,” there has been a sub-net roam to adifferent server. The result of this logic is to either signal a subsetroam, and out of range condition or a no server condition (or none ofthese) to the calling process.

FIG. 18 shows a flowchart of example steps performed by a Mobile EndSystem 104 roaming control center. To enable roaming at the Mobile EndSystem 104, the list of known addresses is initialized to zero (block850) and an operating system interface change notification is enabled(block 852). The process then calls the operating system to get a listof current addresses that use DHCP (block 854). All known addresses nolonger in the current list have their corresponding listeners closed(block 856). Similarly, the process opens listeners on all current butnot known interfaces (block 858). The process then signals “roam” toregistrants (block 860).

When the listener process of FIG. 17 signals (block 862), the processdetermines whether the signal indicates a “roam”, “out of range” or“back in range” condition (decision block 864, 870, 874). A roam signal(“yes” exit to decision block 864) causes the process to closecorresponding listener 866 and call the operating system to release andrenew DHCP lease to a network address (block 868). If the listenersignals “out of range” (decision block 870), the process signals thiscondition to registrants (block 872). If the signal is a “back in range”(decision block 874), then this condition is signaled to all registrants(block 876). Upon receiving a disabled roam command (block 878), theprocess closes all listeners (block 880) and disables the operatingsystem interface change notification (block 882).

EXAMPLES

A presently preferred exemplary embodiment of present invention findsapplication in a variety of real-world situations. For example:

Intermittently Connected Portable Computer

Many businesses have employees who occasionally telecommute or work fromhome. Such employees often use laptop computers to get their work done.While at work, the employees typically connect their laptop computers toa local area network such as an Ethernet through use of a docking portor other connector. The LAN connection provides access to networkservices (e.g., printers, network drives) and network applications(e.g., database access, email services).

Now suppose an employee working on a project needs to go home for theevening and wants to resume working from home. The employee can“suspend” the operating system and applications running on the laptopcomputer, pack up the laptop computer, and bring the laptop computerhome.

Once home, the employee can “resume” the operating system andapplications running on the laptop computer, and reconnect to the officeLAN via a dialup connection and/or over the Internet. The MobilityManagement Server (which continued to proxy the laptop computervis-a-vis the network and its applications during the time the laptopcomputer was temporarily suspended) can re-authenticate the laptopcomputer and resume communicating with the laptop computer.

From the perspective of the employee now working from home, all of thenetwork drive mappings, print services, email sessions, databasequeries, and other network services and applications, are exactly wherethe employee left them at the office. Furthermore, because the MobilityManagement Service continued to proxy the laptop computer's sessions,none of those network applications terminated the laptop computer'ssessions during the time the employee was traveling from the office tohome. The exemplary embodiment of the invention thus provides efficientpersistence of session across the same or multiple network mediums thatis very powerful and useful in this and other contexts.

Mobile Inventory and Warehouse Application

Imagine a large warehouse or retail chain. Within this campus, inventoryworkers use vehicle mounted (i.e., trucks and forklifts) personal laptopcomputers and handheld data collection units and terminals to performinventory management of goods. Warehouse and retail workers are ofteninexperienced computer users that do not understand network sub-nets andrequire management supervision. A presently preferred exemplaryembodiment of present invention allows the creation of a turnkey systemthat hides the complexity of the mobile network from the warehouseusers. The users can move in and out of range of access points, suspendand resume their Mobile End Systems 104, and change locations withoutconcern for host sessions, network addresses, or transport connections.In addition, the management software on the Mobility Management Server102 provides management personnel with metrics such as number oftransactions, which may be used to gauge worker productivity. Managementcan also use the network sub-net and access points to determine worker'slast known physical location.

Mobile Medical Application

Imagine a large hospital using radio LAN technology for networkcommunications between several buildings. Each building is on a uniquesub-net. A presently preferred exemplary embodiment of present inventionenables nurses and doctors to move from room to room with handheldpersonal computers or terminals—reading and writing patient informationin hospital databases. Access to the most recent articles on medicationand medical procedures is readily available through the local databaseand the World Wide Web. While in the hospital, pagers (one and two way)are no longer required since a presently preferred exemplary embodimentof the present invention allows continuous connection to the Mobile EndSystem 104. Messages can be sent directly to medical personnel via theMobile End System 104. As in the case with warehouse workers, medicalpersonnel are not required to understand the mobile network they areusing. In addition, the Mobile End System 104 allows medical personnelto disable radio transmission in area where radio emissions are deemedundesirable (e.g., where they might interfere with other medicalequipment)—and easily resume and reconnect where they left off.

Trucking and Freight

Freight companies can a presently preferred exemplary embodiment of usethe present invention to track inventory. While docked at a warehouse,the Mobile End System 104 may use LAN technology to update warehouseinventories. While away from local services, the Mobile End System 104can use Wide Area WAN services such as CDPD and ARDIS to maintain realtime status and location of inventory. The Mobile End System 104automatically switches between network infrastructures—hiding thecomplexity of network topology from vehicle personnel.

Mobile Enterprise

Corporate employees may use the system in accordance with a presentlypreferred exemplary embodiment of present invention for access toE-mail, web content and messaging services while within an enterprisecampus that has invested in an infrastructure such as 802.11. The costof ownership is reduced since pager service and other mobile deviceservices are no longer required. The purchase of mobile infrastructureis a one time capital expense as opposed to the costly “pay-per-use”model offered by many existing mobile device services.

IP Multiplication

If an organization has a LAN that needs to be connected to the Internet,the administrator of the LAN has two choices: get enough globallyassigned addresses for all computers on the LAN, or get just a fewglobally assigned addresses and use the Mobility Management Server 102in accordance with a presently preferred exemplary embodiment of thepresent invention as an address multiplier. Getting a large number of IPaddresses tends to be either expensive or impossible. A small companyusing an Internet Service Provider (ISP) for access to the Internet canonly use the IP addresses the ISP assigns—and the number of IP addresseslimits the number of computers that can be on the Internet at the sametime. An ISP also charges per connection, so the more computers thatneed to be on the Internet, the more expensive this solution becomes.

Using the Mobility Management Server 102 in accordance with the presentinvention as an address multiplier could solve many of these problems.The enterprise could put the Mobility Management Server 102 on hardwarethat is connected to the Internet via an ISP. Mobile End Systems 104could then easily connect. Because all connection to the Internet wouldgo through the Mobility Management Server 102, only one address from theISP is required. Thus, using a presently preferred exemplary embodimentof the present invention as an address multiplier allows the enterpriseto get just a few (in many cases one) addresses and accounts from theISP, and allows the entire LAN to have simultaneous connections to theInternet (assuming enough bandwidth is provided).

While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the scope ofthe appended claims.

1. A method for enabling secure data communication with a computingdevice that roams among plural data communication networks orsubnetworks of the type that carry Internet Protocol (IP) data, saidmethod comprising: establishing access to at least one datacommunications network or subnetwork carrying IP data; using saidnetwork or subnetwork to institute secure data communications betweensaid computing device and another computing device; upon said computingdevice roaming while operational to a further network or subnetworkcarrying IP data, establishing access at the computing device with saidfurther network or subnetwork to enable said computing device tocommunicate over said further network or subnetwork; participating in aDHCP process with said further network or subnetwork; learning, at leastin part in response to said DHCP process, that said computing device isenabled to communicate over said further network or subnetwork; based atleast in part on said learning, informing said another computing devicethat said computing device has roamed and has access to said furthernetwork or subnetwork; and using said access to said further network orsubnetwork to continue said secure data communications between thecomputing device and said another computing device.
 2. The method ofclaim 1 wherein said computing device comprises a mobile computingdevice that communicates wirelessly with said at least one datacommunications network or subnetwork and said further network orsubnetwork.
 3. The method of claim 1 wherein said another computingdevice comprises an intermediary computing device.
 4. The method ofclaim 1 wherein said another computing device comprises a server.
 5. Themethod of claim 1 wherein said another computing device comprises aproxy server.
 6. The method of claim 1 wherein the at least one datacommunications network or subnet carrying IP data and the further datacommunications network or subnet carrying IP data provide a homogeneouscollection of link layer data communication networks or subnetworks. 7.The method of claim 1 wherein the at least one data communicationsnetwork or subnet carrying IP data and the further data communicationsnetwork or subnet carrying IP data provide a heterogeneous collection oflink layer data communication networks or subnetworks.
 8. The method ofclaim 1 wherein said participating includes sending a discover message.9. The method of claim 1 wherein said learning compares a networkaddress dynamically provided by DHCP with a previously-used networkaddress, and determines whether said addresses are different.
 10. Themethod of claim 1 wherein said computing device performs saidparticipation, said DHCP process dynamically provides a network addressto said computing device, and said method further includes using saiddynamically-provided network address to continue said securecommunications via said further network or subnetwork.
 11. The method ofclaim 1 wherein said learning includes detecting, based on a networkaddress that is dynamically provided by said DHCP process, that saidcomputing device's network point of attachment has changed.
 12. Themethod of claim 1 further including authenticating or reauthenticatingsaid continued secure communications in response to learning saidcomputing device has roamed.
 13. The method of claim 1 wherein said datacommunications network or subnetwork is wireless, and said further datacommunications network or subnetwork is non-wireless.
 14. The method ofclaim 1 wherein said data communications network or subnetwork isnon-wireless, and said further data communications network or subnetworkis wireless.
 15. The method of claim 1 wherein said computing devicesupports at least one application layer session, and said roaming allowssaid application layer session to continue without terminating.
 16. Themethod of claim 1 further including changing routing information forsaid secure communications to continue.
 17. The method of claim 1further including intercepting calls at the transport driver interface.18. The method of claim 1 further including intercepting calls at thesocket API level.
 19. The method of claim 1 further includingestablishing said secure communications with said computing device usingUDP.
 20. The method of claim 1 further including issuing a ping check todetermine if the computing device temporarily lost and then regainedcontact with a sub-network, but has not roamed to a differentsub-network.
 21. The method of claim 1 wherein said computing devicecomprises a laptop computer with a display, a keyboard and a wirelessinterface.
 22. The method of claim 1 wherein said computing devicecomprises a mobile medical computing device.
 23. The method of claim 1further including providing configurable session priorities for saidcomputing device and/or users thereof.
 24. The method of claim 1 whereinthe point of presence address of said computing device changes duringroaming, and wherein said method further includes maintaining a constantvirtual address associated with said computing device at least duringroaming.
 25. The method of claim 1 wherein said computing device movesfrom one type of connection to another during roaming.
 26. The method ofclaim 1 wherein said computing device connects to said network orsubnetwork and to said further network or subnetwork using differentnetwork interfaces.
 27. A method, performed by a computing device whilethe computing device is operational, for enabling secure datacommunication over at least one data communication network or subnetworkof the type that carries Internet Protocol (IP) data, said methodcomprising: establishing access to at least one data communicationsnetwork or subnetwork carrying IP data; using said network or subnetworkaccess to establish secure data communications with another computingdevice; disassociating access from said network or subnetwork;subsequent to said disassociating step, reestablishing access to saidnetwork or subnetwork; participating in a DHCP process with said networkor subnetwork; learning, at least in part in response to said DHCPprocess, that said computing device has reestablished access to saidnetwork or subnetwork; based at least in part on said learning,informing said another computing device of said reestablished access;and using said reestablished access to continue said secure datacommunications with said another computing device.
 28. The method ofclaim 27 wherein said computing device comprises a mobile computingdevice that communicates wirelessly with said at least one datacommunications network or subnetwork carrying IP data.
 29. The method ofclaim 27 wherein said another computing device comprises an intermediarycomputing device.
 30. The method of claim 27 wherein said anothercomputing device comprises a server.
 31. The method of claim 27 whereinsaid another computing device comprises a proxy server.
 32. The methodof claim 27 wherein the at least one data communications network orsubnet carrying IP data comprises a homogeneous collection of link layerdata communication networks or subnetworks.
 33. The method of claim 27wherein the at least one data communications network or subnet carryingIP data comprises a heterogeneous collection of link layer datacommunication networks or subnetworks.
 34. The method of claim 27wherein said participating includes sending a discover message.
 35. Themethod of claim 27 wherein said learning compares a network addressdynamically provided by DHCP with a previously-used network address, anddetermines whether said addresses are different.
 36. The method of claim27 wherein said computing device performs said participation, said DHCPprocess dynamically supplies a network address to said computing device,and said method further includes using said dynamically supplied networkaddress to continue said secure data communications.
 37. The method ofclaim 27 wherein said learning includes detecting, based on a networkaddress that is dynamically provided by said DHCP process, that anetwork point of attachment has not changed.
 38. The method of claim 27further including authenticating or reauthenticating said continuedsecure data communications.
 39. The method of claim 27 wherein said datacommunications network or subnetwork is wireless.
 40. The method ofclaim 27 wherein said data communications network or subnetwork isnon-wireless.
 41. The method of claim 27 wherein said computing devicesupports at least one application layer session, and said disassociatingdoes not cause said application layer session to terminate.
 42. Themethod of claim 27 further including intercepting calls at the transportdriver interface.
 43. The method of claim 27 further includingintercepting calls at the socket API level.
 44. The method of claim 27further including establishing said secure data communications usingUDP.
 45. The method of claim 27 further including issuing a ping checkto determine if the computing device temporarily lost and then regainedcontact with a sub-network, but has not roamed to a differentsub-network.
 46. The method of claim 27 wherein said computing devicecomprises a laptop computer with a display, a keyboard and a wirelessinterface.
 47. The method of claim 27 wherein said computing devicecomprises a mobile medical computing device.
 48. The method of claim 27further including providing configurable session priorities for saidcomputing device and/or users thereof.
 49. The method of claim 27wherein the point of presence address of said computing device changesduring roaming, and wherein said method further including maintaining avirtual address associated with said computing device constant at leastduring roaming.
 50. The method of claim 27 wherein said computing devicemoves from one type of connection to another on said network orsubnetwork.
 51. The method of claim 27 wherein said computing device canconnect to said network or subnetwork using plural different networkinterfaces.
 52. A method for allowing a mobile computing device to movebetween plural IP-based networks, comprising: connecting the mobilecomputing device to at least one network; using a dynamically-suppliedIP address to enable secure data communications providing applicationand/or transport layer sessions between said mobile computing device andanother computing device; then migrating the mobile computing device toa further network while said mobile computing device is operational;determining, based at least in part on a DHCP process performed on saidfurther network, that said mobile computing device may have moved; andin response to said determining, taking further action to continue saidsecure data communications including said application and/or transportlayer sessions between said moved mobile computing device and saidanother computing device over said further network without terminatingsaid application and/or transport layer sessions.
 53. A method forallowing a mobile computing device to roam across IP-based networks,comprising: connecting the mobile computing device to at least onenetwork medium used for data communications; using a network layeraddress to facilitate secure IP-based data communications includingapplication and/or transport layer sessions between said mobilecomputing device and another computing device at least in part via saidnetwork medium; then connecting the mobile computing device to a furthernetwork medium without first rebooting said mobile computing device;performing a DHCP process over said further network medium; discovering,based at least in part on said DHCP process, that said mobile computingdevice has roamed; and based at least in part on said discovering, usinga further network layer address to continue said secure IP-based datacommunications between said mobile computing device and said anothercomputing device without terminating application and transport layersessions therebetween.
 54. A system for enabling secure datacommunication comprising: plural data communication networks orsubnetworks of the type that carry Internet Protocol (IP) data; a mobilecomputing device that, while operational, roams among said plural datacommunication networks or subnetworks; and another computing device thatcommunicates with said mobile computing device via said plural datacommunications networks or subnetworks, wherein said mobile computingdevice comprises: at least one wireless data communications device forestablishing access to said at least one data communications network orsubnetwork carrying IP data and for using said network or subnetwork toinstitute secure wireless data communications with said anothercomputing device, and upon said mobile computing device wirelesslyroaming while operational to a further network or subnetwork carrying IPdata, for establishing access with said further network or subnetwork toenable said mobile computing device to communicate over said furthernetwork or subnetwork, a listener that participates in a DHCP processwith said further network or subnetwork; a detector coupled to saidlistener, said detector learning, at least in part in response to saidDHCP process, that said mobile computing device is enabled tocommunicate over said further network or subnetwork and, based at leastin part on said learning, using said access to said further network orsubnetwork to continue said secure data communications between themobile computing device and said another computing device.
 55. Acomputing device comprising: data communicators that establishes accessto at least one data communications network or subnetwork carryingInternet Protocol (IP) data over at least one data communication networkor subnetwork, and which uses said access to said network or subnetworkto establish secure data communications with another computing device; aDHCP listener that participates in a DHCP process with said network orsubnetwork upon said computing device disassociating access from saidnetwork or subnetwork and then reestablishing access to said network orsubnetwork, said DHCP listener learning, at least in part in response tosaid DHCP process, that said computing device has reestablished accessto said network or subnetwork; wherein said data communicator informssaid another computing device, based at least in part on said learning,of said reestablished access and uses said reestablished access tocontinue said secure data communications with said another computingdevice.